Э Н Ц И К Л О П Е Д И Я M S - D O S T H E M S - D O S E N C Y C L O P E D I A Microsoft Press, 1988 Перевод с английского Киев 1989 Содержание ПРЕДИСЛОВИЕ . . . . . . . . . . . . . . . . . . . . . . . . . . 2 РАЗДЕЛ I. Разработка MS-DOS . . . . . . . . . . . . . . . . . 7 РАЗДЕЛ II. Программирование и среде MS-DOS . . . . . . . . . . . 39 ЧАСТЬ А. Структура MS-DOS Глава 1. 1. Введение в MS-DOS . . . . . . . . . . . . . . . . . 39 1.1. Загрузчик ОС . . . .EXE-программе . . . . . . . 41 1.2. BIOS . . . . . . . . . . . . . . . . . . . . . . . 41 1.3. Ядро MS-DOS . . . . . . . . . . . . . . . . . . . . 42 1.3.1. Управление процессом . . . . . . . . . . . . . . . 42 1.3.2. Управление памятью . . . . . . . . . . . . . . . . 43 1.3.3 Обслуживание внешних устройств. . . . . . . . . . . 43 1.3.4. Файловая система . . . . . . . . . . . . . . . . 44 1.4 Пользовательский интерфейс . . . . . . . . . . . . 44 1.5 Вспомогательные программы . . . . . . . . . . . . 45 1.6 Версии ОС . . . . . . . . . . . . . . . . . . . . 45 2. Основные требования к MS-DOS . . . . . . . . . . . 48 Глава 2. Компоненты MS-DOS . . . . . . . . . . . . . . . . 53 1. Основные элементы . . . . . . . . . . . . . . . . . 54 1.1. BIOS . . . . . . . . . . . . . . . . . . . . . . . 54 1.2. Ядро MS-DOS . . . . . . . . . . . . . . . . . . . . 55 1.3. Командный процессор . . . . . . . . . . . . . . . . 56 1.3.1. Разделение обязанностей в COMMAND.COM . . . . . . . 57 1.3.2. Выполнение команд . . . . . . . . . . . . . . . . . 57 1.3.3. Cреда MS-DOS . . . . . . . . . . . . . . . . . . . 58 1.3.4. Командные файлы . . . . . . . . . . . . . . . . . 59 1.3.5. Переадресация ввода/вывода . . . . . . . . . . . . 60 2. Загрузка MS-DOS . . . . . . . . . . . . . . . . . 62 2.1. Первоначальная загрузка . . . . . . . . . . . . . . 62 2.2. Cистемная инициализация MS-DOS (SYSINIT) . . . . . 65 2.3. Запуск командного процессора . . . . . . . . . . . 70 2.3.1. COMMAND.COM . . . . . . . . . . . . . . . . . . 72 2.3.2. Пользовательские программы командного процессора. . 75 Глава 3. Запоминающие устройства в MS-DOS . . . . . . . . . 80 1. Структура диска . . . . . . . . . . . . . . . . . . 81 1.1. Схема физического блочного устройства . . . . . . . 81 1.1.1. Виртуальные диски . . . . . . . . . . . . . . . . . 81 1.1.2. Физические диски . . . . . . . . . . . . . . . . . 82 1.1.3. Дорожки . . . . . . . . . . . . . . . . . 82 1.1.4. Головки внешних устройств . . . . . . . . . . . . 83 1.1.5. Секторы . . . . . . . . . . . . . . . . . . . . . 84 1.1.6. Чередование . . . . . . . . . . . . . . . . . . . . 85 1.2. Cтруктура распределения разделов диска . . . . . . 85 1.3. Структура файловой системы . . . . . . . . . . . . 87 1.3.1. Cектор начальной загрузки . . . . . . . . . . . . 89 1.3.2. Таблица размещения файлов . . . . . . . . . . . . 92 1.3.3. Особые соображения . . . . . . . . . . . . . . 94 1.3.4. Корневой каталог . . . . . . . . . . . . . . . 96 1.3.5. Область файла . . . . . . . . . . . . . . . 98 2. Другие запоминающие устройства. . . . . . . . . . . 99 ЧАСТЬ B. Программирование в MS-DOS . . . . . . . . . . . . . . 100 Глава 4. Структура прикладной программы . . . . . . . . . . . . 100 1. .EXE-программа . . . . . . . . . . . . . . . . . 101 1.1. Передача управления .EXE-программе . . . . . . . 101 1.1.1. Префикс сегмента программы . . . . . . . . . . . 101 1.1.2. Стек . . . . . . . . . . . . . . . . . . . . . . 106 1.1.3. Предварительно распределенная память . . . . . . 106 1.1.4. Регистры . . . . . . . . . . . . . . . . . . . . 108 1.2. Завершение .EXE-программы . . . . . . . . . . . . 110 1.2.1. Процесс завершения с помощью функции, возвращающей код завершения . . . . . . . . . . . . . . . . . 110 1.2.2. Прерывание завершения программы . . . . . . . . . 112 1.2.3. Перезапуск из памяти/Вектор завершения . . . . . 113 1.2.4. Команда RET . . . . . . . . . . . . . . . . . . . 113 1.2.5. Функция завершения процесса . . . . . . . . . . . 114 1.2.6. Завершиться и остаться резидентной . . . . . . . 114 1.3. Структура .EXE-файлов . . . . . . . . . . . . . . 115 1.3.1. Заголовок файла . . . . . . . . . . . . . . . . . 115 1.3.2. Загрузочный модуль . . . . . . . . . . . . . . . 119 1.4. Загрузка .EXE-программы . . . . . . . . . . . . . 120 1.5. Управление структурой .EXE-программы . . . . . . 121 1.5.1. Директива макроассемблера SEGMENT . . . . . . . . 122 1.5.1.1. Параметр типа align . . . . . . . . . . . . . . . 122 1.5.1.2. Параметр combine . . . . . . . . . . . . . . . . 124 1.5.1.3. Параметр class . . . . . . . . . . . . . . . . . 125 1.5.1.4. Переупорядочение сегментов с целью уменьшения размеров .EXE-файла . . . . . . . . . . . . . . . 127 1.5.2. Директива GROUP макроассемблера . . . . . . . . . 128 1.5.3. Структурирование небольшой программы с помощью директив SEGMENT и GROUP . . . . . . . . . . . . 129 1.6. Использование современных моделей памяти компиляторов фирмы Microsoft . . . . . . . . . . 133 1.7. Внесение изменений в заголовок .EXE-файла . . . . 137 1.8. Исправление .EXE-программы с помощью утилиты DEBUG 139 1.9. Заключение по .EXE-программам . . . . . . . . . . 140 2. .COM-программа . . . . . . . . . . . . . . . . . 141 2.1. Передача управления .COM-программе . . . . . . . 141 2.2. Завершение .COM-программы . . . . . . . . . . . . 142 2.3. Подготовка .CОM-программы . . . . . . . . . . . . 143 2.4. Исправление .COM-программы с помощью утилиты DEBUG 145 2.5. Заключение по .COM-программам . . . . . . . . . . 146 3. Перечень различий . . . . . . . . . . . . . . . . 147 Глава 5. Символьные устройства ввода/вывода . . . . . . . . . . 149 1. Предистория вопроса . . . . . . . . . . . . . . . 150 2. Доступ к символьным устройствам . . . . . . . . . . 151 3. Основные символьные устройства . . . . . . . . . . 152 3.1. Cтандартные устройства . . . . . . . . . . . . . 153 3.2. Cквозной и фильтрующий режимы обработки . . . . . . 154 3.3. Клавиатура . . . . . . . . . . . . . . . . . . . 153 3.3.1. Pоль BIOS ПЗУ при чтении с клавиатуры . . . . . . . 157 3.3.2. Примеры программирования клавиатуры . . . . . . . 157 3.4. Дисплей . . . . . . . . . . . . . . . . . . . 158 3.4.1. Управление экраном . . . . . . . . . . . . . . . 159 3.4.2. BIOS ПЗУ , роль при выводе на дисплей . . . . . . . 160 3.4.3. Примеры программирования дисплея . . . . . . . 161 3.5. Последовательные коммуникационные порты . . . . . 162 3.5.1. Примеры программирования последовательного порта 163 3.6. Параллельный порт и принтер . . . . . . . . . . . . 164 4. Управление вводом - выводом (IOCTL) . . . . . . . . 166 4.1 . Примеры программирования с использованием IOCTL 167 Глава 6. Управление коммуникациями на основе прерываний . . . . 168 1. Цель создания программ коммуникаций . . . . . . . 169 2. Использование простых функций MS-DOS . . . . . . 170 3. Используемые аппаратные средства . . . . . . . . 172 3.1. Модем . . . . . . . . . . . . . . . . . . . . . . 172 3.2. Последовательный порт . . . . . . . . . . . . . . 173 3.3. Архитектура устройства 8250 UART . . . . . . . . 174 3.3.1. Программный интерфейс устройства 8250 . . . . . . 175 3.3.2. Схемы управления . . . . . . . . . . . . . . . . 176 3.3.3. Схемы состояния . . . . . . . . . . . . . . . . . 179 3.3.4. Программирование устройства UART . . . . . . . . 181 4. Драйверы устройств . . . . . . . . . . . . . . . 184 5. Два альтернативных подхода . . . . . . . . . . . 185 5.1. Традиционный путь . . . . . . . . . . . . . . . . 185 5.2. Альтернативный подход: создание драйвера устройства коммуникации . . . . . . . . . . . . . . . . . . 185 5.3. Сравнение двух методов . . . . . . . . . . . . . 185 6. Пакет программ управления устройствами . . . . . 187 6.1. Драйвер устройства COMDVR.ASM . . . . . . . . . . 187 6.1.1. Текст драйвера . . . . . . . . . . . . . . . . . 187 6.1.2. Определения . . . . . . . . . . . . . . . . . . . 204 6.1.3. Заголовки и таблицы структур . . . . . . . . . . 205 6.1.4. Стратегическая программа и программа обработки запросов . . . . . . . . . . . . . . . . . . . . 206 6.1.5. Буферизация . . . . . . . . . . . . . . . . . . . 207 6.1.6. Программы обработки прерываний . . . . . . . . . 208 6.1.7. Программа Start_output . . . . . . . . . . . . . 209 6.1.8. Программа начального инициирования . . . . . . . 210 6.1.9. Использование COMDVR . . . . . . . . . . . . . . 210 6.1.10. Техника отладки драйвера . . . . . . . . . . . . 211 6.2. Простая программная модель модема . . . . . . . . 212 6.3. Утилита установления состояния драйвера: CDVUTL.C 214 7. Традиционный подход . . . . . . . . . . . . . . . 222 7.1. Модуль обслуживания аппаратных прерываний (ISR) . 222 7.2. Модуль обработки особых ситуаций . . . . . . . . 229 7.3. Модуль работы с видеодисплеем . . . . . . . . . . 231 7.4. Пример интеллектуального эмулятора терминала CTERM.C . . . . . . . . . . . . . . . . . . . . . 236 Глава 7. Управление файлами и записями . . . . . . . . . . . . 252 1. История развития . . . . . . . . . . . . . . . . 253 2. Использование функций управления по системному идентификатору . . . . . . . . . . . . . . . . . 255 2.1. Обработка ошибок функций управления по системному идентификатору . . . . . . . . . . . . . . . . . 256 2.2. Создание файла . . . . . . . . . . . . . . . . . 257 2.3. Открытие существующего файла . . . . . . . . . . 259 2.4. Закрытие файла . . . . . . . . . . . . . . . . . 262 2.5. Функции управления чтением и записью по идентификатору . . . . . . . . . . . . . . . . . 262 2.6. Позиционирование указателя чтения/записи . . . . 265 2.7. Другие операции управления файлом по идентификатору 266 2.7.1. Переименование файла . . . . . . . . . . . . . . 267 2.7.2. Удаление файла . . . . . . . . . . . . . . . . . 268 2.7.3. Получение/установка атрибутов файла . . . . . . . 268 2.7.4. Получение/установка даты и времени создания файла 269 2.7.5. Функции дублирования и переназначения . . . . . . 270 3. Использование функций, основанных на FCB . . . . 272 3.1. Структура блока управления файлом (FCB) . . . . . 272 3.2. Функции, основанные на FCB,и PSP . . . . . . . . 276 3.3. Синтаксический анализ имени файла . . . . . . . . 276 3.4. Обработка ошибок и функции, основанные на FCB . . 277 3.5. Создание файла . . . . . . . . . . . . . . . . . 278 3.6. Открытие файла . . . . . . . . . . . . . . . . . 278 3.7. Закрытие файла . . . . . . . . . . . . . . . . . 279 3.8. Чтение и запись файлов при помощи FCB . . . . . . 280 3.8.1. Последовательный доступ: чтение . . . . . . . . . 281 3.8.2. Последовательный доступ: запись . . . . . . . . . 281 3.8.3. Произвольный (прямой) доступ к записи: чтение . . 281 3.8.4. Произвольный доступ к записи: запись . . . . . . 282 3.8.5. Произвольный доступ к блоку: чтение . . . . . . . 282 3.8.6. Произвольный доступ к блоку: запись . . . . . . . 282 3.9. Другие операции с файлом, использующие FCB . . . 284 3.9.1. Переименование файла . . . . . . . . . . . . . . 284 3.9.2. Удаление файла . . . . . . . . . . . . . . . . . 285 3.9.3. Нахождение размера файла и проверка его существования . . . . . . . . . . . . . . . . . . 286 4. Заключение . . . . . . . . . . . . . . . . . . . 287 Глава 8. Дисковые каталоги и метки тома . . . . . . . . . . . . 288 1. Логическая структура каталогов MS-DOS . . . . . . 290 1.1. Поиски каталогов . . . . . . . . . . . . . . . . 290 1.2. Добавление и уничтожение статей каталога . . . . 290 1.3. Текущий каталог . . . . . . . . . . . . . . . . . 290 2. Формат каталога . . . . . . . . . . . . . . . . . 291 2.1. Формат входа каталога . . . . . . . . . . . . . . 291 3. Метки тома . . . . . . . . . . . . . . . . . . . 294 4. Функциональная поддержка для каталогов MS-DOS . . 295 4.1. Поиск в каталоге . . . . . . . . . . . . . . . . 298 4.1.1. Шаблонные символы . . . . . . . . . . . . . . . . 298 4.2. Анализ входа каталога . . . . . . . . . . . . . . 299 4.3. Видоизменение входа каталога . . . . . . . . . . 299 4.4. Создание и уничтожение каталогов . . . . . . . . 300 4.5. Определение текущего каталога . . . . . . . . . . 300 4.6. Примеры программирования: поиск файлов . . . . . 300 4.7. Пример программирования: изменение метки тома . . 305 Глава 9. Управление памятью . . . . . . . . . . . . . . . . . . 310 1. Стандартная память . . . . . . . . . . . . . . . 311 1.1. Управление стандартной памятью со стороны MS-DOS 312 1.2. Использование функций управления памятью . . . . 314 2. Расширенная память (Expanded memory) . . . . . . 319 2.1. Программа управления расширенной памятью (EMM) . 319 2.1.1. Проверка наличия расширенной памяти . . . . . . . 321 2.1.2. Использование расширенной памяти . . . . . . . . 323 3. Дополнительная память (Extended memory) . . . . . 331 4. Заключение . . . . . . . . . . . . . . . . . . . 335 Глава 10. Функция EXEC MS-DOS . . . . . . . . . . . . . . . . . 336 1. Как работает EXEC . . . . . . . . . . . . . . . . 337 2. Использование EXEC для загрузки программы . . . . 339 2.1. Выделение памяти . . . . . . . . . . . . . . . . 339 2.2. Подготовка параметров для EXEC . . . . . . . . . 339 2.2.1. Имя программы . . . . . . . . . . . . . . . . . . 340 2.2.2. Блок параметров . . . . . . . . . . . . . . . . . 340 2.2.3. Описание среды . . . . . . . . . . . . . . . . . 341 2.2.4. Хвост команды . . . . . . . . . . . . . . . . . . 342 2.2.5. Неявные блоки управления файлом . . . . . . . . . 343 2.3. Выполнение подзадачи . . . . . . . . . . . . . . 343 2.3.1. Особенности для различных версий . . . . . . . . 344 2.4. Проверка кодов возврата подзадачи . . . . . . . . 345 2.5. Использование COMMAND.COM вместе с EXEC . . . . . 345 2.6. Пример главной задачи и подзадачи . . . . . . . . 346 3. Использование EXEC для загрузки оверлейных программ 353 3.1. Выделение оперативной памяти . . . . . . . . . . 353 3.2. Подготовка параметров оверлейной программы . . . 354 3.3. Загрузка и выполнение оверлейной программы . . . 354 3.4. Пример оверлейной программы . . . . . . . . . . . 355 ЧАСТЬ С. Настройка MS-DOS . . . . . . . . . . . . . . . . . . . 362 Глава 11. Утилиты типа 'завершиться и остаться резидентным' . . 362 1. Структура утилиты типа 'завершиться и остаться резидентным' . . . . . . . . . . . . . . . . . . 363 1.1. Ввод с клавиатуры . . . . . . . . . . . . . . . . 364 1.2. Обработка прерываний ПЗУ-BIOS . . . . . . . . . . 364 1.3. Обработка аппаратных прерываний . . . . . . . . . 365 1.4. Обработка функций MS-DOS . . . . . . . . . . . . 365 2. Поддержка MS-DOS программ типа 'завершиться и остаться резидентным' . . . . . . . . . . . . . . 366 2.1. Функции 'завершиться и остаться резидентным' . . 367 2.1.1. Функция 31H прерывания 21H . . . . . . . . . . . 368 2.1.2. Прерывание 27H . . . . . . . . . . . . . . . . . 368 2.1.3. Управление TSR-программой в ОЗУ . . . . . . . . . 368 2.2. Функции установки и получения вектора прерывания 368 2.3. Функции получения и установки адреса префикса сегмента программы (PSP) . . . . . . . . . . . . 369 2.4. Функции установки и получения расширенной информации об ошибке . . . . . . . . . . . . . . 369 2.5. Функции установки и получения адреса области передачи данных (DTA) . . . . . . . . . . . . . . 370 2.6. Прерывание во время ожидания (MS-DOS idle interrupt) (Прерывание 28H) . . . . . . . . . . . 370 3. Определение состояния MS-DOS . . . . . . . . . . 371 3.1. Внутренние стеки MS-DOS . . . . . . . . . . . . . 371 3.2. Флаг критической ошибки . . . . . . . . . . . . . 371 3.3. Флаг InDOS . . . . . . . . . . . . . . . . . . . 373 4. Мультиплексное прерывание . . . . . . . . . . . . 375 5. Примеры TSR-программ . . . . . . . . . . . . . . 376 5.1. HELLO.ASM . . . . . . . . . . . . . . . . . . . . 376 5.2. SNAP.ASM . . . . . . . . . . . . . . . . . . . . 378 5.2.1. Установка этой программы . . . . . . . . . . . . 403 5.2.2. Обнаружение 'горячей' последовательности клавиш . 403 5.2.3. Активизация прикладной части программы . . . . . 403 5.2.4. Выполнение резидентной прикладной программы . . . 405 Глава 12. Средства обработки особых ситуаций . . . . . . . . . 407 1. Обзор . . . . . . . . . . . . . . . . . . . . . . 408 2. Обработка Control-C . . . . . . . . . . . . . . . 409 2.1. Специализированная обработка ситуации Control-C . 409 2.2. Примечания к обработке Control-C . . . . . . . . 412 3. Обработка критических ошибок . . . . . . . . . . 413 3.1. Механизм обработки критической ошибки . . . . . . 415 3.1.1. Ошибки при обращении к блочному устройству (ошибки, связанные с диском) . . . . . . . . . . . . . . . 415 3.1.2. Ошибки при обращении к символьному устройству . . 416 3.2. Выполнение обработки критических ошибок . . . . . 417 3.3. Специализированные обработчики критических ошибок 418 4. Прерывания в аппаратно генерируемых особых ситуациях . . . . . . . . . . . . . . . . . . . . 422 4.1. Деление на ноль (прерывание 00H) . . . . . . . . 422 4.2. Пошаговый режим (прерывание 01H) . . . . . . . . 423 4.3. Прерывание в точке останова (прерывание 03H) . . 423 4.4. Прерывание по переполнению (прерывание 04H) . . . 424 4.5. Превышение границы (прерывание 05H) . . . . . . . 424 4.6. Неверный код операции (прерывание 06H) . . . . . 424 5. Дополнительная информация об ошибках . . . . . . 425 5.1. Функция 59H и более старые системные обращения . 430 5.2. Функция 59H и более новые системные обращения . . 431 Глава 13. Обработка аппаратных прерываний . . . . . . . . . . . 434 1. Классы аппаратных прерываний . . . . . . . . . . 436 1.1. Приоритеты прерываний в компьютерах семейства 8086 436 1.2. Программы обработки прерываний . . . . . . . . . 437 2. Особенности маскируемых прерываний . . . . . . . 438 2.1. Непредсказуемость . . . . . . . . . . . . . . . . 438 2.2. Быстрая смена информации . . . . . . . . . . . . 438 3. Обработка маскируемых прерываний . . . . . . . . 440 3.1. Программируемый контроллер прерываний 8259A . . . 442 3.2. Уровни прерываний . . . . . . . . . . . . . . . . 442 3.2.1. Восьмиуровневая конструкция . . . . . . . . . . . 443 3.2.2. Шестнадцатиуровневая конструкция . . . . . . . . 443 4. Программирование для аппаратных прерываний . . . 445 4.1. Пример новой программы обработки прерывания . . . 445 4.2. Дополнительные обработчики . . . . . . . . . . . 449 5. Заключение . . . . . . . . . . . . . . . . . . . 452 Глава 14. Разработка фильтров в системе MS-DOS . . . . . . . . 453 1. Системная поддержка для фильтров . . . . . . . . 454 2. Принципы работы фильтров . . . . . . . . . . . . 456 3. Разработка фильтров . . . . . . . . . . . . . . . 457 4. Использование фильтров в качестве порожденных процессов . . . . . . . . . . . . . . . . . . . . 468 Глава 15. Устанавливаемые драйверы устройств . . . . . . . . . 474 1. Резидентные и устанавливаемые драйверы . . . . . 476 1.1. Драйверы символьно-ориентированных устройств . . 476 1.2. Драйверы блочно-ориентированных устройств . . . . 478 2. Структура драйверов устройств в MS-DOS . . . . . 479 2.1. Заголовок устройства . . . . . . . . . . . . . . 479 2.2. Подпрограмма стратегии (Strat) . . . . . . . . . 481 2.3. Подпрограмма прерывания (Intr) . . . . . . . . . 483 2.3.1. Функции кода команды . . . . . . . . . . . . . . 484 2.3.2. Функция инициализации . . . . . . . . . . . . . . 485 2.3.3. Функция проверки носителей . . . . . . . . . . . 487 2.3.4. Функция построения блока параметров BIOS (BPB) . 489 2.3.5. Функции чтения, записи и записи с верификацией . 491 2.3.6. Функция чтения без разрушения . . . . . . . . . . 493 2.3.7. Функции состояния ввода и состояния вывода . . . 494 2.3.8. Функции очистки входного буфера и очистки выходного буфера . . . . . . . . . . . . . . . . . . . . . 495 2.3.9. Функции чтения и записи управления вводом/выводом (IOCTL) . . . . . . . . . . . . . . . . . . . . . 495 2.3.10. Функции 'Открыть устройство' и 'Закрыть устройство' 496 2.3.11. Функция 'Съемные носители' . . . . . . . . . . . 497 2.3.12. Функция 'Вывод до тех пор, пока не занято' . . . 498 2.3.13. Функция общего управления вводом/выводом (IOCTL) 498 2.3.14. Функции получения и установки параметров логического устройства . . . . . . . . . . . . . 500 3. Обработка типичного запроса ввода/вывода . . . . 502 4. Написание драйверов устройств . . . . . . . . . . 504 4.1. Пример символьного драйвера: TEMPLATE (Шаблон) . 505 4.2. Пример драйвера блочно-ориентированного устройства: TINYDISK (Маленький диск) . . . . . . . . . . . . 512 П Р Е Д И С Л О В И Е Операционная система MS-DOS, разработанная фирмой Microsoft, яв- ляется в настоящее время самым распространенным программным продуктом в мире. Она работает более чем на десяти миллионах персональных компь- ютеров во всем мире и является основой для разработки по крайней мере 20000 прикладных систем - это наибольшее количество приложений, имею- щихся для различных операционных систем. Как промышленный стандарт для семейства компьютеров, оснащенных процессором 8086, MS-DOS сыграла главную роль в революции, произведенной персональными компьютерами, и является наиболее значительным и наиболее продолжительным фактором в развитии изначальной установки фирмы Microsoft: "Компьютер на каждый рабочий стол и в каждый дом". Возможность разработки единой операцион- ной системы для всего разнообразия базирующихся на процессоре 8086 персональных компьютеров и прикладных систем казалась невероятной, но фирме Microsoft удалось создать такую систему - MS-DOS, выпущенную на рынок в 1981 году. Настоящей мерой успеха при этом является то, что MS-DOS занимала и продолжает занимать выдающееся положение в микро- компьютерной индустрии. Со времени создания MS-DOS на рынке появились более мощные и зна- чительно усовершенствованные компьютеры, так что для каждой новой вер- сии MS-DOS пересматриваются ее позиции как вычислительной среды и для новых, и для старых прикладных систем. Чтобы объяснить это необычное положение, следует обратиться к истокам индустрии персональных компь- ютеров. Тремя наиболее значительными факторами в создании MS-DOS были революция совместимости, разработка Microsoft BASIC и его широкое рас- пространение в области персональных компьютеров, и решение фирмы IBM создать компьютер с 16-разрядной адресацией. Революция совместимости началась с создания микропроцессора Intel 8080. В результате этого технологического прорыва в развивающейся мик- рокомпьютерной промышленности появились беспрецедентные возможности, обещающие постоянное улучшение мощности, скорости и стоимости настоль- ных вычислительных систем. На рынке мини-вычислительных машин каждый разработчик технических средств использует свои множество команд и операционную систему, так что программное обеспечение, разработанное для некоторой конкретной ЭВМ, несовместимо с программным обеспечением для машин других разработчиков. Такая специализация означала также дублирование огромного объема работ - каждый разработчик технических средств должен был писать компиляторы, СУБД и другие программные сред- ства, подходившие только для его отдельной вычислительной машины. Соз- дание микрокомпьютера на микропроцессоре 8080 обещало изменить эту си- туацию, так как различные разработчики стали бы использовать один и тот же микропроцессор с одним и тем же набором команд. За период с 1975 по 1981 год (это эра 8-разрядных микрокомпьюте- ров) фирма Microsoft фактически убедила каждого из изготовителей пер- сональных компьютеров - Radio Shack, Commodore, Apple и десятки других - встроить Microsoft BASIC в свои машины. Первое время для компьютеров всех разработчиков ощущалась нехватка единого языка. Успех BASIC проде- монстрировал преимущества совместимости: пользователи наконец получили возможность переносить прикладное программное обеспечение с вычисли- тельных машин одной фирмы на другие. Большинство вычислительных машин, созданных во время этого ранне- го периода, были без встроенных дисководов. Однако, постепенно гибкие диски, и позднее фиксированные диски, стали менее дорогими и более доступными, и на рынке появился ряд дисковых программ, таких как WordStar и dBase. Стало возможным исключительно важное принятие единой стандартной дисковой операционной системы, которая могла бы поддержи- вать все эти разработки, и это привело к тому, что фирмы Lifeboat, Microsoft и Digital Research стали использовать СР/М-80, дисковую опе- рационную систему фирмы Digital Research для микропроцессора 8080. Эпоха 8-разрядных персональных компьютеров подтвердила важность наличия единого стандарта, который позволил бы свободный обмен прог- раммами. Было важно, чтобы программное обеспечение, разработанное для 16-разрядных вычислительных машин, имело те же преимущества. Ни один из изготовителей персональных компьютеров в 1980 году не мог абсолютно точно предсказать, насколько быстро будет развиваться индустрия прог- раммного обеспечения и как быстро будет получен мощный стандарт - стандарт, который будет жизненной силой индустрии программного обеспе- чения. Подробности того, как MS-DOS стала наиболее распространенной 16-разрядной операционной системой, в частности, работа, которую фирма Microsoft выполняла для фирмы IBM, в данном контексте несущественны. Существенно то, что появление единой операционной системы для 16-раз- рядных вычислительных машин было неизбежным, подобно тому, как Microsoft BASIC был распространен для 8-разрядных систем. Было совершенно ясно, что персональные компьютеры получили широ- кое признание на рынке, когда журнал "Time" в 1982 году назвал персо- нальный компьютер "героем года". MS-DOS неразрывно связана с этим признанием и популярностью, и фирма Microsoft продолжала адаптировать MS-DOS для более мощных ЭВМ, без нарушения совместимости, что естест- венно при поддержке промышленного стандарта. Появление микропроцессора 80386 подтвердило, что такие постоянные разработки в области программ- ного обеспечения для архитектуры процессора Intel не были напрасными и стоят того, чтобы их продолжать. Целью написания "Энциклопедии MS-DOS" было создать наиболее пол- ное и доступное руководство для программистов MS-DOS . Размеры этой книги во много раз превосходят размер распечаток исходных текстов пер- вой версии MS-DOS - очевидность растущей сложности и изощренности этой операционной системы. "Энциклопедия" будет особенно полезна для разра- ботчиков программного обеспечения, столкнувшихся со все возрастающими требованиями к мобильности их приложений. Нашей бурно развивающейся промышленности удалось использовать преимущества, предоставляемые защищенным режимом (protected mode), по- явившимся с микропроцессором 80286 и виртуальным режимом, появившимся с микропроцессором 80386. MS-DOS будет продолжать играть центральную роль в этих разработках. Более быстродействующие и более мощные компь- ютеры, на которых работает операционная система OS/2 фирмы Microsoft , знаменуют захватывающее будущее мультизадачных вычислительных систем, вычислительных сетей, усовершенствованных уровней защиты данных, улуч- шенном управлении аппаратной памятью для большого числа приложений, великолепных графических систем, которые могут продемонстрировать ин- терфейс пользователей-непрофессионалов и подсистемы коммуникаций. Вер- сия 3 MS-DOS, которая работает в реальном режиме на персональных ком- пьютерах, оснащенных микропроцессорами 80286 и 80386, является свя- зующим звеном в семействе API - интерфейсов прикладных программ - опе- рационной системы OS/2. Пользователи по-прежнему будут в выигрыше от будущих работ фирмы Microsoft по улучшению производительности операци- онных систем и удобства их использования. Билл Гейтс За шесть лет MS-DOS стала самой распространенной операционной системой в мире. Она развилась, окрепла и превратилась в гибкую, легко расширяемую систему, которая может поддерживать и работу в вычисли- тельной сети, и графический пользовательский интерфейс, и почти все периферийные устройства, и даже ПЗУ-компакт-диски , содержащие огром- ные объемы актуальной информации. MS-DOS будет еще использоваться в течение многих лет, как основа для прикладных систем, работающих на недорогих, оснащенных микропроцессорами 8086/8088 вычислительных маши- нах. Не удивительно, что успех MS-DOS вовлек в его орбиту многих писа- телей и публицистов. Количество книг по MS-DOS и его командам, языкам и прикладным системам превосходит списки подобной литературы для любой другой операционной системы. Зачем же тогда издавать еще одну книгу по MS-DOS ? И что еще мы можем сказать об операционной системе такого, что еще не было сказано? Во-первых, мы писали и издавали "Энциклопедию MS-DOS" в расчете только на одну аудиторию: сообщество работающих программистов. Следо- вательно, мы имели возможность опустить некоторые элементарные сведе- ния, такие как количество бит в байте или интерпретация шестнадцате- ричных чисел. Вместо этого мы приводим подробные технические объясне- ния, примеры работающих программ, которые могут быть адаптированы и включены в новые прикладные системы, и системный взгляд на наиболее общие команды и утилиты MS-DOS. Во-вторых, поскольку мы не были ограничены объемом, то рассматри- вали глубже те вопросы, которые в других книгах по MS-DOS только крат- ко упоминаются, например, исключение и обработка ошибок, связи, управ- ляемые по прерыванию, стратегии отладки, управление памятью и инстол- ляция драйверов устройств. Мы выделили отдельные главы по перемещаемым объектным модулям, генерируемым трансляторами языков Microsoft, по ра- боте редактора связей объектных модулей Microsoft ( Microsoft Object Linker) и по резидентным служебным программам. Мы даже беседовали с основными разработчиками MS-DOS и позаимствовали их файлы, чтобы пре- доставить читателю занимательный, иллюстрированный перечень исходных фрагментов стандартно устанавливаемой операционной системы фирмы Microsoft. И , наконец, объединяя представления и опыт программистов других фирм, знания и материалы исследований разработчиков программного обес- печения фирмы Microsoft и издательскую технологию Microsoft Press, мы создали уникальное и исчерпывающее руководство по средствам, командам, директивам и служебным утилитам MS-DOS. Во многих случаях рукопись бы- ла прорецензирована авторами описываемых программных средств фирмы Microsoft. Во время создания этой книги мы сделали все, что в наших силах, чтобы ее содержимое было актуальным и достоверным. Однако, в работе такого объема неизбежны ошибки и неточности. Если вы обнаружите что- либо подобное, сообщите нам о них, чтобы в последующих изданиях они были исправлены; тем самым вы поможете своим братьям-программис- там. С этой целью Microsoft Press открыла свой абонентский пункт в элек- тронной почте MCI для внесения исправлений и комментариев. Рэй Дункан В В Е Д Е Н И Е "ЭНЦИКЛОПЕДИЯ MS-DOS" - это самое полное из всех руководств по промышленно-стандартной операционной системе MS-DOS , разработанной фирмой Microsoft. Оно написано в расчете на опытных пользователей и программистов персональных компьютеров и содержит подробную, специфи- ческую для каждой версии информацию о всех командах, утилитах и сис- темных обращениях MS-DOS , а также статьи признанных специалистов по некоторым конкретным областям программирования для MS-DOS . Весь этот богатейший материал разбит на большие тематические разделы, каждый из которых имеет формат, определяющийся его содержанием. Структура книги "Энциклопедия MS-DOS" состоит из пяти больших разделов и приложе- ний. Каждый раздел имеет свою собственную внутреннюю структуру; там, где это необходимо, помещены разъясняющие вводные заметки. Раздел I. РАЗВИТИЕ MS-DOS. В этом разделе представлена история развития стандарта операционной системы, разработанной фирмой Microsoft, начиная с его непосредственных предшественников и заканчи- вая версией 3.2. Раздел II. ПРОГРАММИРОВАНИЕ В СРЕДЕ MS-DOS. Этот раздел разбит на пять частей: - структура MS-DOS; - программирование для MS-DOS; - установка MS-DOS; - направления развития MS-DOS; - средства программирования. Каждая из этих частей содержит ряд статей известных специалистов по этим вопросам. В статьи включены многочисленные рисунки, таблицы и примеры программ, которые обеспечивают возможность подробного изучения предмета. Раздел III. КОМАНДЫ ПОЛЬЗОВАТЕЛЯ. В этом разделе в алфавитном по- рядке представлены все внутренние и внешние команды MS-DOS , такие как ANSI.SYS, BATCH, CONFIG.SYS, DRIVER.SYS, EDLIN, RAMDRIVE.SYS и VDISK.SYS. Каждая команда представлена в таком виде, который позволяет опытному пользователю быстро уточнить синтаксис команды и ограничения, накладываемые на переменные; менее опытный пользователь может обра- титься к более детальному обсуждению команды и ее использования. Раздел IV. ПРОГРАММНЫЕ УТИЛИТЫ. Этот раздел организован так же, как и раздел "Команды пользователя", чтобы предоставить разработанные фирмой Microsoft программные средства, включая DEBUG, SYMDEB и отлад- чик CodeView. Хотя некоторые из этих утилит поставляются только с ком- пиляторами языков программирования фирмы Microsoft и не включаются в систему MS-DOS или дополнительные диски, но их использование сущест- венно при программировании для MS-DOS , и поэтому для полноты руковод- ства по операционной системе они включены в "Энциклопедию". Раздел V. СИСТЕМНЫЕ ОБРАЩЕНИЯ. Приложения А - О. Р А З Д Е Л I Р А З Р А Б О Т К А M S - D O S Для многих пользователей персональных компьютеров операционная система MS-DOS является тем ключом, с помощью которого они получают доступ к мощным средствам вычислительной машины. Это их наиболее ощу- тимая связь с аппаратными средствами, упрятанными вовнутрь корпуса, и именно посредством MS-DOS они могут выполнять прикладные программы, управлять дисками и файлами на дисках. Поскольку MS-DOS открывает возможности работы с персональным ком- пьютером, то она в самом деле является ключом, и этот ключ подходит ко всему семейству вычислительных машин, в основу которых положен мик- ропроцессор 8086. MS-DOS и микропроцессоры, с которыми она работает, фактически, тесно связаны - настолько тесно, что создание MS-DOS на самом деле является частью большого периода истории, охватывающего не только операционную систему, но также и историю микропроцессора и, ог- лядываясь в прошлое, частью подобного взрыву развития самих персональ- ных компьютеров. Хронологически, история разработки MS-DOS может быть разделена на три периода. Она началась с образования фирмы Microsoft и событий, предшествовавших решению Microsoft разрабатывать операционную систему. Затем была создана первая версия MS-DOS. И , наконец, был период пос- тоянного развития MS-DOS с момента ее выпуска в 1981 году. 1. Предшественники MS-DOS Роль International Business Machines Corporation в решении компа- нии Microsoft создать MS-DOS хорошо известна. Но события, такие как изобретения, всегда основываются на предыдущих достижениях, и в этом плане корни MS-DOS идут далеко в прошлое, к четырем аппаратным и прог- раммным разработкам 70-х годов: ориентированная на работу с дисками и операционно-независимая версии языка BASIC, разработанные фирмой Microsoft ; операционная система СР/M-80 фирмы Digital Research; появ- ление микропроцессора 8086 и дисковой операционной системы для него, разработанной Тимом Патерсоном, работавшим тогда в компании Seattle Computer Products, которая занималась разработкой аппаратных средств. 1.1. Microsoft и BASIC На первый взгляд может показаться, что Basic и MS-DOS имеют очень мало общего, но с точки зрения организации управления файлами, MS-DOS является прямым последователем версии BASIC фирмы Microsoft, называе- мой Операционно-независимый Дисковый BASIC (Stand-alone Disk BASIC). Еще даже перед тем, как Microsoft стала компанией, ее основатели, Пол Аллен и Билл Гейтс, разработали версию BASIC для произвевшего пе- реворот маленького компьютера, названного Altair, выпущенного в январе 1975 года фирмой Micro Instrumentation Telemetry Systems (MITS), кото- рая находилась в г. Альбукерк, шт. Нью-Мексико. Хотя его скоро затмили другие разработки и модели, Altair был первым "персональным" компьюте- ром, появившимся в мире мини- и больших ЭВМ. Это был просто металли- ческий ящик с панелью переключателей и индикаторов для ввода и вывода, с блоком питания, генмонтажной платой с восемнадцатью разъемами и еще двумя платами. На одной плате находился центральный процессор с 8-раз- рядным микропроцессором Intel 8080; другая плата обеспечивала 256 байт оперативной памяти. У этого миниатюрного компьютера не было ни клавиа- туры, ни монитора, ни устройства постоянной памяти, но он обладал од- ним огромным достоинством: розничной ценой 397 долл. В 1975 г. работы с вычислительной техникой была еще прерогативой специалистов по обработке данных. Поэтому когда для Altair появились 4-Кбайтные платы расширения памяти, то программным обеспечением, необ- ходимым большинству его пользователей, были не текстовый редактор или электронная таблица, а язык программирования - и первым языком, разра- ботанным для него, была версия BASIC, написанная Биллом Гейтсом и По- лом Алленом. Гейтс и Аллен увлекались вычислительной техникой еще со школы (и вместе создали машину для чтения информации, записанной на 16-дорожеч- ной, 4-цифровой магнитной ленте с бинарной кодировкой, базировавшуюся на процессоре 8008, предшественнике процессора 8080, того самого, ко- торым была оснащена вычислительная машина Altair). Пол Аллен узнал о вычислительной машине Altair из январского вы- пуска журнала Popular Electronics (1975 г.). Аллен, тогда служащий фирмы Honeywell в Бостоне, уговорил Гейтса, студента Гарвардского уни- верситета, разработать BASIC для этого нового компьютера. Вдвоем они написали свою версию BASIC за шесть недель, и Аллен полетел в Нью-Мек- сико, чтобы продемонстрировать этот язык в MITS. Разработчики назвали свою компанию Microsoft и продали лицензию на свой BASIC фирме MITS как на первый продукт фирмы Microsoft. Хотя он и не являлся непосредственным предшественником MS-DOS, Altair BASIC , как и вычислительная машина, для которой он был разра- ботан, был поворотной вехой в истории персональных компьютеров. С дру- гой стороны, Altair BASIC был также первым звеном в цепи, которая ве- ла, несколько окольными путями, к Тиму Патерсону и его дисковой опера- ционной системе, которую он разработал для фирмы Seattle Computer Products для микропроцессора 8086. 1.1.1. От перфоленты к диску Первая версия BASIC Гейтса и Аллена для Altair загружалась с пер- фоленты, после того как программа загрузки ленты вводилась в память при помощи переключателей на передней панели компьютера. Однако,в кон- це 1975 года MITS решила выпустить систему гибких дисков для Altair - первую систему гибких дисков, появившуюся в розничной продаже. В ре- зультате, в феврале 1976 года Аллен, к тому времени уже Директор по программному обеспечению в MITS, попросил Гейтса написать ориентиро- ванную на работу с дисками версию Altair BASIC. У вычислительной маши- ны Altair не было операционной системы и, следовательно, она не имела средств управления файлами, так что дисковый BASIC должен был содер- жать некоторые служебные программы по управлению файлами. Он должен был, фактически, функционировать как примитивная операционная система. Гейтс, все еще находившийся в Гарвардском университете, написал программы в течение пяти дней, и по прошествии еще пяти дней отладки, Disk BASIC работал на Altair. Эта ориентированная на работу с дисками версия BASIC ознаменовала вступление компании Microsoft в область разработки языков программиро- вания для персональных компьютеров - не только для Altair фирмы MITS, но также и для таких компаний, как Data Terminals Corporations и General Electric. На этом пути BASIC фирмы Microsoft приобретал допол- нительные характеристики, такие как расширенные математические средст- ва, и постепенно эволюционировал в Stand-alone Disk BASIC, созданный для компании NCR в 1977 году. Спроектированный и запрограммированный Марком МакДональдом, Stand-alone Disk BASIC содержал схему управления файлами, названную FAT (file allocation table - таблица размещения файлов), которая ис- пользовала список со ссылками (цепной список) для организации файлов на диске. FAT, родившаяся в одной из многих дискуссий МакДональда и Билла Гейтса, обеспечивала хранение информации о размещении файлов на диске в одном месте, при этом "связанные в цепь" ссылки указывали на физическое размещение областей памяти на диске. Быстрая и гибкая, эта структура управления файлами была позже использована в автономной вер- сии BASIC для микропроцессора 8086 и, в конечном счете, через операци- онную систему М-DOS, стала основой программ по управлению файлами в MS-DOS. 1.2. M-DOS В течение 1977 и 1978 годов Microsoft адаптировала BASIC и Microsoft FORTRAN для 8-разрядной операционной системы, названной СР/М, популярность которой тогда возрастала. В конце 1978 года Гейтс и Аллен перенесли Microsoft из Альбукерка в г. Белльвью, шт. Вашингтон. Компания продолжала работать над языками программирования, разрабаты- вая версии BASIC для 6502 и ТI9900. В течение этого же периода Марк МакДональд также работал над 8-разрядной операционной системой , названной M-DOS (обычно произно- сится как "Мидас" или "Май ДОС" (My DOS - моя DOS). Хотя она никогда не стала реальным продуктом фирмы Microsoft, M-DOS была настоящей мно- гозадачной операционной системой, спроектированной по аналогии с опе- рационной системой TOP-10 фирмы DEC. M-DOS обеспечивала хорошую произ- водительность и , с более гибкой FAT, чем встроенная в BASIC, имела лучшую структуру управления файлами, чем у подававшей надежды операци- онной системы СР/М. Однако, занимавшая около 30 Кбайт, M-DOS была к сожалению слишком велика для восьмиразрядных вычислительных систем и поэтому кончила тем, что была сдана в архив (микропроцессор 8080 может адресоваться только к 64 Кбайт оперативной памяти). 1.3. СР/М На заре эры персональных компьютеров, в период с 1976 до 1978 года, и пользователи, и разработчики персональных компьютеров быстро пришли к осознанию ограничений работы прикладных программ на основе Stand-Alone Disk BASIC фирмы Microsoft или любого другого языка. Фирма MITS, например, запланировала к июлю 1976 года выпуск независимой опе- рационной системы для своей вычислительной машины, в которой использо- вались тексты программ Disk BASIC, разработанного для Altair. В том же году фирма Digital Research, возглавлявшаяся Гарри Килделлом, выпусти- ла свою операционную систему Control Program Monitor, или СР/М. СР/М была типичным микрокомпьютерным программным продуктом 70-х годов, так как она была написана одним человеком, а не группой, и для того, чтобы удовлетворить конкретные потребности в области, для кото- рой еще ничего не было создано. Одним из наиболее интересных моментов в истории СР/М является то, что это программное средство было разрабо- тано за несколько лет до того, как оно было выпущено на рынок - факти- чески, аппаратные средства, на которых СР/М стала стандартом, появи- лись в продаже за несколько лет до этого. Версия СР/М, разработанная в 1973 году Килделлом, тогда профессо- ром вычислительных наук в Морской Высшей Школе в г. Монтрей, шт. Кали- форния, претерпела ряд изменений. Килделл усовершенствовал отладчик и ассемблер СР/М, добавил интерпретатор BASIC и проделал некоторую рабо- ту над редактором, в конце концов разработав программный продукт, кото- рый, с 1977 года и до появления Personal Computer фирмы IBM, был стан- дартом операционной системы для 8-разрядных вычислительных машин. СР/М фирмы Digital Research включала интерпретатор, названный ССР (Console Command Processor - процессор команд консоли), который дейст- вовал как интерфейс между пользователем и самой операционной системой, и систему управления всей работой, названную BDOS (Basic Disk Operating System - базовая дисковая операционная система), которая от- вечала за хранение файлов, управление каталогом и выполняла другие ру- тинные работы. Для настоящего ввода и вывода - ввода/вывода на диски, экран дисплея, на печатающее устройство и тому подобное - в СР/М была включена BIOS (Basic Input/Output System - базовая система ввода/выво- да), зависевшая от ограничений той аппаратуры, на которой работала операционная система. Для хранения файлов СР/М использовала схему восьмисекторных бло- ков размещения (allocation units). Для каждого данного файла блоки размещения были перечислены в элементе каталога, который содержал имя файла и таблицу, задающую схему расположения на диске шестнадцати бло- ков размещения. Если для большого файла требовалось больше, чем 16 блоков, СР/М создавала дополнительные элементы каталога. Доступ к не- больщим файлам в этой системе осуществлялся быстро, но для больших файлов, с более чем одним элементом каталога, могли потребоваться мно- гочисленные, относительно емкие по времени обращения к диску в поисках необходимой информации. Однако, несмотря на сказанное, СР/М была высоко оценена и пользо- валась поддержкой широких кругов разработчиков как программных, так и технических средств. Достаточно мощная для своего размера (4 Кбайта), она была, во всех отношениях, бесспорным стандартом в мире восьмираз- рядных вычислительных машин, и оставалась им до, и даже после появле- ния микропроцессора 8086. 1.4. Микропроцессор 8086 Когда фирма Intel выпустила в 1974 году 8-разрядный микропроцес- сор 8080, до создания вычислительной машины Altair оставался еще год. Процессор 8080 был спроектирован не для того, чтобы сделать вычисли- тельную технику частью повседневной жизни, а лишь для того, чтобы сде- лать бытовые приборы и промышленные механизмы более "умными". К 1978 году, когда фирма Intel выпустила 16-разрядный микропроцессор 8086, микрокомпьютер стал реальностью, и новый микропроцессор представлял собой большой шаг вперед по быстродействию и объему памяти. Полные 16ти-разрядные шины микропроцессора 8086 позволяли ему работать быст- рее, чем 8080, и его возможность обращаться к 1 мегабайту оперативной памяти была гигантским шагом по сравнению с 64-Кбайтным объемом памяти микропроцессора 8080. Хотя 8086 не был совместим с 8080, он по архи- тектуре был подобен своему предшественнику, и исходные тексты программ могли быть механически оттранслированы, чтобы выполняться на нем. Эта возможность трансляции, фактически, очень сильно повлияла на разработ- ку Тимом Патерсоном его операционной системы для микропроцессора 8086 и, через работы Патерсона, на первую выпущенную версию MS-DOS . Когда микропроцессор 8086 появился на арене, фирма Microsoft , подобно другим разработчикам, стояла перед выбором: продолжать рабо- тать в знакомом мире восьмиразрядных вычислительных систем или обра- титься к более широким горизонтам, предоставляемым 16-разрядной техни- кой. Со временем, Microsoft сделала и то , и другое. Действуя по предложению Пола Аллена, компания разработала SoftCard - плату с программным обеспечением - для распространенного персонального компьютера Apple II, который базировался на 8-разряд- ном микропроцессоре 6502. SoftCard содержала микропроцессор Z80 и ко- пию СР/М-80, поставляемую по лицензии фирмы Digital Research. С по- мощью SoftCard пользователи Apple II могли выполнять любую программу или использовать любой язык, разработанный для СР/М-машины. Компания Microsoft вступила на арену 16-разрядных вычислитель- ных машин так же, как она это сделала с Altair: разработкой операцион- но-независимой версии BASIC для микропроцессора 8086. В то же самое время и, по случайному совпадению, несколькими ми- лями южнее, в г. Таквила, шт. Вашингтон, сотрудник компании Seattle Computer Products, создававшей платы памяти, занимался разработкой платы центрального процессора на основе микропроцессора 8086 для вы- числительной машины с магистралью (шиной) S-100. 1.5. 86-DOS Патерсон познакомился с микропроцессором 8086 на семинаре, прово- дившемся фирмой Intel в июне 1978 года. Он посетил семинар по предло- жению своего работодателя, Рода Брока из компании Seattle Computer Products. После семинара Патерсон - опять при поддержке Брока - начал рабо- тать с микропроцессором 8086. Он закончил проектирование своей первой платы центрального процессора на микропроцессоре 8086 в январе 1979 года, и к концу весны разработал работающий центральный процессор, а также ассемблер и монитор для 8086. В июне Патерсон привез свою систе- му в Microsoft, чтобы попробовать, как будет на ней работать Stand-alone BASIC, и вскоре Microsoft BASIC работал на новой плате фирмы Seattle Computer. В начале июня Microsoft и Патерсон посетили национальную конфе- ренцию по вычислительной технике, проходившую в Нью-Йорке. Патерсон познакомился с операционной системой M-DOS фирмы Microsoft, которую он нашел интересной, так как в ней использовалась система для отслежива- ния дорожек для файлов, размещенных на дисках - FAT, разработанная для Stand-alone BASIC - которая отличалась от всего, что он до этого вст- речал. После этого Патерсон продолжал работать над платой для 8086, и к концу года Seattle Computer Products начала продавать плату централь- ного процессора с возможностью дополнительного приобретения BASIC. В апреле 1980 года, когда разработка СР/М-86 еще не была заверше- на, Seattle Computer Products решила разработать собственную операци- онную систему для 16-разрядных машин. Изначально планировалась раз- работка трех операционных систем: однопользовательская система, много- пользовательская версия и небольшой промежуточный продукт, вскоре не- формально окрещенный Патерсоном как QDOS (Quick and Dirty Operating System - быстрая и черновая операционная система). И Патерсон, работавший над QDOS, и Род Брок знали, что создание стандартной операционной системы для микропроцессора 8086 необходимо, если пользователи хотят с уверенностью использовать широкий набор прикладного программного обеспечении и языков. СР/М была стандартом для 8-разрядных вычислительных машин, так что возможность механически транслировать существующие для СР/М прикладные программы для выполне- ния их на 16-разрядных вычислительных системах стала одной из глав- ных целей Патерсона при разработке новой операционной системы. Чтобы добиться такой совместимости, система, которую он разрабатывал, имити- ровала функции и структуру команд СР/М-80, включая использование бло- ков управления файлами (file control blocks - FCBs) и ее подхода к вы- полняемым файлам. Однако, в то же время Патерсон был неудовлетворен некоторыми эле- ментами СР/М, один из которых - ее система размещения файлов, которую он считал неэффективной и при использовании пространства на диске, и слишком медленной в работе. Поэтому для быстрого, эффективного управ- ления файлами он использовал таблицу размещения файлов, как это сдела- ла фирма Microsoft в операционно-независимой дисковой версии языка BASIC и M-DOS. Он также написал транслятор для перевода программ , на- писанных для 8080, в программы для 8086, и затем написал ассемблер на языке ассемблера процессора Z80 и использовал транслятор, чтобы транс- лировать его. Через четыре месяца после начала работы у Патерсона была работаю- щая операционная система объемом 6 Кбайт, официально названная 86-DOS, и в сентябре 1980 года он опять связался с фирмой Microsoft, на этот раз чтобы попросить компанию написать версию BASIC, которая бы работа- ла в его системе. 1.6. IBM Пока Патерсон разрабатывал 86-DOS, третий главный фактор, привед- ший к созданию MS-DOS, набирал силу на противоположном конце страны. Фирма IBM, до тех пор, казалось, смотревшая сквозь пальцы на большинс- тво разработок в области микрокомпьютеров, обратила свое внимание н возможность разработки небольшой рабочей станции для рынка, который она хорошо знала: бизнес и бизнесмены. 21 августа 1980 года группа представителей фирмы IBM из г. Бока Рэтон, шт. Флорида, посетили фирму Microsoft . Эта группа, возглавляе- мая Джеком Сэмсом, поведала Microsoft о заинтересованности фирмы IBM в разработке компьютера, базирующегося на микропроцессоре. IBM, однако, чувствовала себя неуверенно в области микрокомпьютерной технологии и микрокомпьютерного рынка. Традиционно, фирма IBM рассчитывает на длин- ный цикл разработки - обычно, четыре или пять лет - и фирма опасалась, что такой длинный период разработки не годится для быстроразвивающейся среды микрокомпьютеров. Одним из решений фирмы IBM было взять за основу новой машины раз- работки других производителей. Все необходимые аппаратные средства имелись, но того же самого нельзя было сказать о программном обеспече- нии. Поэтому последовал визит в компанию Microsoft с вопросом: имея спецификацию для 8-разрядного компьютера, не сможет ли Microsoft на- писать аппаратную версию BASIC, ROM BASIC, для него к апрелю следую- щего года? Microsoft ответила положительно, но в свою очередь спросила: По- чему разрабатывается 8-разрядный компьютер? Почему бы вместо этого не выпустить 16-разрядную машину, в которой бы использовался микропроцес- сор 8086 фирмы Intel? После этой встречи - первой из многих - Сэмс и его группа вернулись в Бока Рэтон с предложением о разработке неболь- шой 16-разрядной деловой рабочей станции. Совместное предприятие было названо "Проект Чесс" (Project Chess - проект "шахматы"). Еще месяцем позже Сэмс опять обратился к фирме Microsoft с вопро- сом, не смогут ли Гейтс и Аллен все к той же даже - апрель 1981 года - разработать не только BASIC, но также FORTRAN, Pascal и COBOL для но- вого компьютера. В тот момент ответ был "нет", потому что, хотя BASIC фирмы Microsoft был спроектирован, чтобы работать как операционно-не- зависимый продукт, он был уникален в этом отношении - другим языкам нужна была операционная система. Гейтс предложил CP/M-86, которая тог- да еще разрабатывалась фирмой Digital Research, и фактически осущест- вил для IBM первый контакт . Однако, Digital Research и IBM не пришли ни к какому соглашению. Фирма Microsoft, между тем, все еще хотела написать все эти языки для IBM, - приблизительно 400 Кбайт исходных текстов программ. Но чтобы сделать это за отведенные по плану шесть месяцев, компании нужна была уверенность в том, какую операционную систему будет использовать фирма IBM. Более того, ей нужна была конкретная информация о внутренних час- тях операционной системы, так как ROM BASIC должен был очень тесно взаимодействовать с BIOS. 1.6.1. Поворотная точка В воскресенье, 28 сентября 1980 года фирма Microsoft находилась в состоянии неопределенности. В этот день (вечером за чашкой кофе, в ка- бинете Гейтса) Аллен и Гейтс пересмотрели предложение компании Microsoft фирме IBM. Их оценка - объем программ в 400 Кбайт - включала четыре языка, ассемблер и редактор связей. Если добавить операционную систему, то это потребует еще только 20 Кбайт или около того (в дейс- тительности, это заняло чуть больше 12 Кбайт в добавок к 400 Кбайтам), и они уже знали о работающей модели операционной системы для микропро- цессора 8086: 86-DOS Тима Патерсона. Компания Seatle Computer Products, которая не занималась торгов- лей программным обеспечением, продала лицензию на 86-DOS фирме Microsoft . В октябре 1980 года, имея в руках 86-DOS, Microsoft представила на рассмотрение компании IBM еще одно предложение. На этот раз план включал разработку и операционной системы, и языков для нового компь- ютера. Времени было мало, и границы между языками и операционной сис- темой были неясными, так что Microsoft объяснила, что она должна конт- ролировать разработку операционной системы, чтобы гарантировать выпуск ее к весне 1981 года. В ноябре фирма IBM подписала контракт. 2. Создание MS-DOS В конце ноября прототип машины IBM прибыл в Microsoft . Первой задачей, стоявшей перед компанией, был перенос 86-DOS на новую машину. Это была трудная задача, так как работа должна была выполняться в пос- тоянно изменяющейся аппаратной среде, так как изменения также вноси- лись и в сами спецификации на создающиеся вычислительную операционную системы. Как часть этого процесса, необходимо было перекомпилировать 86-DOS и интегрировать ее с BIOS, которую фирма Microsoft помогала IBM написать. Эта задача усложнялась из-за особенностей программных сред- ств и носителя информации, на котором они были записаны. 86-DOS Патер- сона - не содержавшая такие утилиты, как EDLIN, CHKDSK и INIT (позднее названная FORMAT) - поступила в Microsoft как одна большая программа, написанная на языке ассемблера, на 8-дюймовом гибком диске. В машине фирмы IBM, однако, использовались 5,25-дюймовые диски, так что фирме Microsoft надо было определить формат нового диска и затем найти спо- соб переноса операционной системы из старого формата в новый. Эта работа, выполнявшаяся Бобом О'Риаром, распалась на ряд шагов. Во-первых, он перенес часть кодов программы с 8-дюймового диска и ком- пилировал ее. Затем он преобразовал ее в шестнадцатеричный формат Intel. Потом он загрузил ее на DEC-2020 и оттуда выгрузил на фиксиро- ванный диск большой инструментальной системы разработчиков фирмы Intel, со встроенным эмулятором. DEC-2020, использовавшаяся для этой цели, была также использована для разработки BIOS, поэтому пришлось выполнить дополнительную работу по выгрузке BIOS в машину Intel, с преобразованием ее в шестнадцатеричный формат, и переносе ее в инстру- ментальную систему IBM с использованием кросс-компилятора. Определение и реализация дискового формата MS-DOS - отличного от формата, принятого Патерсоном для 8-дюймового диска, - было еще од- ной трудной задачей. Конечной целью Патерсона при разработке 86-DOS была независимость от логических устройств, но во время этого первого этапа разработки операционная система просто должна была быть преобра- зована, чтобы она могла оперировать с логическими записями, не зави- симыми от размера физической записи. Патерсон, все еще работавший в Seattle Computer Products, продол- жал работать над 86-DOS, и к концу 1980 года усовершенствовал ее в части независимости от логических устройств, добавив функции, которые преобразовывали в потокоориентированные записи при чтении или записи нескольких секторов или дорожек, а также записей переменной длины. В дополнение к своим собственным улучшениям, Патерсон также работал над десятками изменений по предложению фирмы Microsoft, от модификации со- общений системы при загрузке до изменений в EDLIN, строковом редакто- ре, который он написал для собственного использования. В процессе всей этой работы, по требованию фирмы IBM о сохранении в тайне ее разработ- ки, Патерсону никогда не называлось имя разработчика оригинального технического продукта и никогда не показывался прототип машины, пока он не уволился из Seattle Computer Products и не поступил на работу в компанию Microsoft в мае 1981 года . И, конечно же, в процессе работы разработчики наталкивались на несметное количество просчетов, кратковременных загадок, технических дефектов и других непредвиденных подробностей, без которых невозможен ни один проект. Это были, например, прерывания на плате последователь- ного интерфейса, которые происходили тогда, когда их не ожидали, и, как крушение планов, технические ограничения, к которым вначале никак не могла приспособиться BIOS, что выливалось в спорадические аварийные ситуации на ранних этапах работы MS-DOS . Однако, несмотря на все эти трудности новая операционная система заработала на прототипе первый раз в феврале 1981 года. В течение пос- ледующих шести месяцев система постоянно улучшалась и расширялась, и ко времени своего первого выхода в свет в августе 1981 года MS-DOS, как и Personal Computer фирмы IBM, на котором она появилась, стала ра- ботающим продуктом для использования дома и на производстве. 3. ВЕРСИЯ 1 (1981 г.) Первый вариант MS-DOS , версия 1.0, еще не была той операционной системой, которую фирма Microsoft рассматривала как окончательную мо- дель для 16-разрядных вычислительных систем. Эта первая версия - вклад Гейтса в MS-DOS - была на самом деле хорошим компромиссным решением между настоящим и будущим по двум важ- ным аспектам: она позволила компании Microsoft включиться в планы раз- работки фирмы IBM и обеспечила совместимость (при перетрансляции прог- рамм) с СР/М. Работавшая только на IBM Personal Computer, MS-DOS состояла из 4000 строк исходных программ на ассемблере и занимала при выполнении 8 Кбайт оперативной памяти. Вместе с утилитами, такими как DEBUG, EDLIN и FORMAT, она была организована в виде трех основных файлов. Один файл, IBMBIO.COM, взаимодействовал с ROM BIOS, находящемся в ПЗУ IBM PC, и содержал системы дискового и символьного ввода/вывода. Второй файл, IBMDOS.COM, содержал ядро DOS, включая интерфейс прикладных программ и программы управления файлами на диске и памятью. Третий файл, COMMAND.COM, был процессором внешних команд - часть MS-DOS, наи- более видимая для пользователя. Чтобы использовать преимущества основных существующих языков программирования и таких распространенных прикладных систем, как WordStar и dBase II, MS-DOS была спроектирована так, чтобы разработчи- ки программного обеспечения могли автоматически транслировать исходные тексты программ, написанных для микропроцесора 8080, чтобы выполнять их на 8086. Благодаря этой связи MS-DOS выглядела и работала как опе- рационная система для 8-разрядных машин СР/М, все еще остававшаяся на то время стандартом операционной системы для микрокомпьютеров. Как и в СР/М, в MS-DOS использовались имена файлов, состоящие не более чем из восьми символов, с трехсимвольными расширениями, а также в ней были приняты аналогичные соглашения для идентификации дисководов в соответ- ствующих командах. Большей частью в MS-DOS использовался тот же коман- дный язык, предоставлялись такие же средства управления файлами, и она имела такую же общую структуру, как и СР/М. На программном уровне сходство было еще более поразительным, с почти однозначным соответст- вием в СР/М и MS-DOS организации системных обращений, доступных для прикладных программ. 3.1. Новые свойства MS-DOS, спроектированная Microsoft, однако, не была ни двойником СР/М, ни системой, неразрывно связанной с IBM PC. В надежде создать продукт, который будет пользоваться успехом длительное время, компания Microsoft предприняла ряд шагов, чтобы сделать MS-DOS достаточно гиб- кой при появлении изменений и новых направлений в технологии техничес- ких средств - дисков, плат памяти, даже микропроцессоров - от которых она зависела. Первый шаг по направлению к этой независимости от конк- ретной конфигурации аппаратного обеспечения проявился в версии 1.0 MS-DOS в виде организации ввода/вывода, не зависящего от устройств, использования записей переменной длины, перемещаемых программных фай- лов и заменяемого процессора команд. Организация ввода/вывода, независимого от устройств, была обеспе- чена в MS-DOS тем, что обращение к периферийным устройствам происходи- ло так, как если бы они были файлами. Чтобы сделать это, каждому из трех различавшихся системой устройств было присвоено зарезервированное имя файла: CON для консоли (дисплей и клавиатура), PRN для печатающего устройства и AUX для вспомогательных (auxilary) последовательных пор- тов (интерфейсов). Когда бы ни появлялось в блоке управления файлом одно из этих зарезервированных имен, для файла, названного в команде, все операции направлялись на конкретное устройство, а не в файл на диске. (Блок управления файлом, или FCB (file control block) - это служебная запись длиной 37 байт, находящаяся в области памяти, отве- денной для прикладных программ. Она содержит, среди прочего, имя фай- ла, его расширение, и информацию о размере и начальном адресе при раз- мещении файла на диске.) Такая независимость от устройств была выгодна и разработчикам прикладного программного обеспечения, и пользователям ЭВМ. С точки зрения разрабочиков, это означало, что прикладные программы могут ис- пользовать один набор обращений для чтения и записи, а не большое ко- личество различных обращений для различных устройств, поэтому приклад- ные программы не надо будет изменять, если к вычислительной системе будут добавлены новые устройства. С точки зрения пользователя, незави- симость от устройств означала большую гибкость. Например, даже если программа была написана только для ввода/вывода на диск, пользователь мог также использовать некоторый файл для ввода или выводить результа- ты прямо на печатающее устройство. Другим шагом по направлению к логической независимости было ис- пользование записей переменной длины. В СР/М длина логической и физи- ческой записей была одинакова: 128 байт. Доступ к файлам можно было получить только по блокам в 128 байт, и размеры файлов всегда были кратны 128 байтам. Однако, в MS-DOS размер физического сектора не дол- жен был волновать пользователя. Операционная система имела дело с раз- мерами файлов, которые были точно равны длине файлов в байтах, и на нее можно было полностью положиться при поддержке логических записей любого требуемого размера. Еще одним новым свойством MS-DOS были перемещаемые программные файлы. В отличие от СР/М, MS-DOS имела возможность загружать программ- ные файлы двух различных типов, определяющихся расширениями .COM и .EXE. Программные файлы с расширением .COM имитировали двоичные файлы СР/М. Они были более компактны, чем файлы типа .EXE и загружались нес- колько быстрее, но размер объединенных текста программ, стэка и данных не должен был превышать 64 Кбайт. С другой стороны, программа типа .ЕХЕ могла иметь значительно большие размеры, так как ее файл мог со- держать несколько сегментов, каждый из которых размером до 64 Кбайт. Когда эти сегменты находились в памяти, MS-DOS использовала часть за- головка файла, таблицу переадресаций (relocation table), чтобы автома- тически устанавливать действительные адреса при каждом обращении к сегменту. В дополнение к поддержке файлов типа .ЕХЕ, процессор внешних ко- манд в MS-DOS, COMMAND.COM, был сделан более гибким, так как был офор- млен в виде отдельного перемещаемого файла, как и любая другая прог- рамма. Следовательно, он мог быть заменен любым специализированным процессором команд, при этом новый файл также должен был называться COMMAND.COM. 3.2. Производительность Каждый, кто знаком с IBM PC, знает, что MS-DOS со временем стала доминирующей операционной системой для персональных компьютеров, бази- рующихся на микропроцессоре 8086. Для этого было несколько причин, не последняя из которых - приемлемость MS-DOS как операционной системы для получившего феноменальный успех ряда персональных компьютеров фир- мы IBM. Не смотря на то, что MS-DOS была единственной операционной системой тогда, когда начали продаваться первые IBM PC, это гордое одиночество еще не гарантировало (с неизбежностью) ее способности по- бедить в конкурентной борьбе СР/М-86, появившуюся на шесть месяцев позже. MS-DOS предоставляла значительные преимущества пользователям в целом ряде областей, включая и размещение и управление пространством памяти на диске. Как и СР/М, MS-DOS делит пространство на диске на блоки размеще- ния (allocation units). Однако, в отличие от СР/М, MS-DOS отображает использование этих блоков размещения в центральную таблицу размещения файла (FAT - file allocation table), которая всегда находится в опера- тивной памяти. В обеих операционных системах используется элемент ка- талога для записи информации о каждом файле, но в то время, как эле- мент каталога CP/M включает таблицу распределения памяти (allocation map) - список из шестнадцати 1-Кбайтных блоков размещения, в которые были записаны последовательно части файла,- элемент каталога MS-DOS указывает только на один блок размещения в FAT, а каждый блок в табли- це уже указывает следующий блок, связанный с файлом. Таким образом, в СР/М могло потребоваться несколько элементов каталога (и более, чем одно обращение к диску), чтобы разместить файл, объем которого превы- шает 16 Кбайт, а в MS-DOS полная информация обо всех компонентах файла и о свободных фрагментах памяти на диске находится в оперативной памя- ти, и вовсе нет необходимости обращаться к диску. В результате, MS-DOS получила возможность находить и размещать на дисках даже очень длинные файлы значительно быстрее, чем СР/М. Две другие важные характеристики - возможность читать и записы- вать по несколько записей посредством одного обращения к операционной системе, и временное использование памяти процессором команд MS-DOS - обеспечили дальнейшее улучшение эффективности работы и конечных поль- зователей и разработчиков. Независимость логической записи от физического сектора положила основание для возможности чтения и записи нескольких секторов. При чтении нескольких записей в СР/М, прикладная программа должна была со- держать обращение к функции чтения для каждого сектора в отдельности. При использовании MS-DOS прикладная программа может содержать одно об- ращение к функции чтения, задавая операционной системе первую запись и количество записей, которые следует прочитать, и MS-DOS затем загружа- ет в память все соответствующие сектора автоматически. Другим новым свойством версия 1.0 MS-DOS было разделение процес- сора команд, COMMAND.COM, на резидентную в памяти и временно размещае- мую часть. (Есть также и третья часть, инициализирующая, которая вы- полняет команды из командного файла AUTOEXEC при загрузке. Эта часть COMMAND.COM удаляется из памяти, когда ее работа заканчивается). При- чиной создания резидентной и временной частей процессора команд было желание максимизировать эффективность работы MS-DOS для пользователя. С одной стороны, программисты хотели, чтобы COMMAND.COM включал такие часто используемые функции, как DIR и COPY, для быстроты и удобства их использования; с другой стороны, добавление этих команд означало уве- личение размеров процессора команд, а в результате уменьшение объема памяти, доступной для прикладных программ. Разрешением этого противо- речия между быстродействием и удобством использования было решение включить дополнительные функции во временную часть COMMAND.COM, место в памяти которой могло быть занято любой прикладной программой, кото- рой требовался больший объем оперативной памяти. Чтобы сохранить це- лостность дополнительных функций для пользователя, на резидентную часть COMMAND.COM была возложена обязанность при окончании работы прикладной программы проверять, не разрушена ли его временная часть. Если это необходимо, резидентная часть затем загружает новую копию своего временного партнера в оперативную память. 3.3. Простота использования В дополнение к этим шагам по направлению к повышению эффективнос- ти и независимости от аппаратного обеспечения, MS-DOS включала нес- колько служебных программ и утилит, созданных для того, чтобы облег- чить жизнь пользователей и прикладных программистов. Среди этих слу- жебных средств были улучшенные средства по обработке ошибок, автомати- ческая регистрация дисков, дат и времени последнего обновления файлов, а также обработка пакетов команд (командных файлов). MS-DOS и IBM PC предназначались для не-технических категорий пользователей, и поэтому с самого начала IBM подчеркивала важность це- лостности данных. Поскольку потеря данных наиболее вероятна при непра- вильной реакции пользователя на сообщение об ошибке, были направлены усилия на уточнение еще имевшихся неопределенных сообщений MS-DOS . Чтобы уменьшить риск неправильной интерпретации, фирма Microsoft ис- пользовала эти сообщения последовательно во всех функциях и утилитах MS-DOS, и рекомендовала прикладным программистам использовать те же самые сообщения везде, где это возможно, в их прикладных программах. В дальнейших попытках защитить и сохранить данные, MS-DOS также стала прослеживать устойчивые неисправности - такие как критические ошибки аппаратного обеспечения - раньше это было возложено на аппарат- но-зависимую логику. Теперь аппаратная логика могла просто сообщать о природе ошибки, а операционная система - обрабатывать ситуации после- довательным и систематическим образом. MS-DOS может также отслеживать последовательность прерывающих символов Control-C, так что прикладная программа может быть либо защищена от случайного завершения ее пользо- вателем, либо может обеспечить "красивый" выход в соответствующем мес- те. Чтобы сократить количество ошибок и упростить работу с системой, MS-DOS также автоматически обновляет информацию в оперативной памяти о диске при ее изменении. В СР/М пользователи должны были регистриро- вать новые диски, если они их меняли - трудоемкая и сложная процедура в системе с одним дисководом, или когда данные хранятся на нескольких дисках. В MS-DOS новые диски регистрируются автоматически, как только будет открыт хотя бы один файл. Еще одним новым свойством - это можно увидеть при помощи команды DIR - была отметка о дате и времени последнего обновления фалов на диске. Даже на ранней стадии своей разработки, MS-DOS отслеживала сис- темную дату и высвечивала ее всякий раз при загрузке, то теперь, когда оказалось, что в элементе каталога для хранения информации о заголовке файла необходимо использовать только первые 16 байт, программисты MS-DOS решили использовать некоторые из остающихся 16 байт для записи даты и времени создания или обновления (а также размера) файла. Обработка пакетов команд была вначале добавлена в MS-DOS, чтобы помочь фирме IBM. IBM хотела, чтобы выполнялись "сценарии" - последо- вательности команд или других операций - одна за другой для тестирова- ния различных функций системы. Чтобы сделать это, тестирующим програм- мам нужен был метод автоматического последовательного вызова служебных программ. В результате был создан процессор пакетов команд, который позже также предоставил пользователям удобную возможность сохранения и выполнения команд MS-DOS в командных файлах. И наконец, в MS-DOS увеличено количество возможностей, имеющихся у программ после их завершения. Например, в менее сложных операционных системах прикладные и другие программы остаются в памяти только пока они активны; по окончании работы они удаляются из оперативной памяти. Однако, в MS-DOS добавлена функция, позволяющая оставлять программы резидентными в памяти после их выполнения (так называемые terminate-and-stay-resident programs), которая блокирует программу в памяти и, фактически, делает ее частью среды операционной системы, по- ка сама вычислительная система не будет отключена или перезагружена. 3.4. Рынок Когда IBM аннонсировала свой Personal Computer, то утверждалось, что на новой машине будут работать три операционные системы: MS-DOS, СР/М-86 и p-System фирмы SofTech Microsystem. Из этих трех систем только MS-DOS была готова к тому времени, когда начала продаваться IBM PC. Несмотря на это, к моменту готовности девять из десяти программ, по оценкам журнала InfoWorld за 1981 год, работала под управлением CP/M-80, и симпатии большинства авторов публикаций и обзоров в деловой прессе были на стороне СР/М-86, которая была готова на шесть месяцев позже. Вполне понятно, что MS-DOS сравнивали с СР/М-80 и, позже, с СР/М-86. Основным предметом сравнения была совместимость: до какой степени новая операционная система фирмы Microsoft совместима с сущес- твующим стандартом? Никто в то время не мог предвидеть, что MS-DOS сможет не только угнаться за СР/М, но и превзойти ее. Следует начать с того, что сам успех IBM PC удивил многих обозре- вателей технической прессы. В течение года компания IBM продавала по 30 000 персональных компьютеров в месяц, благодаря, в основном, дело- вому сообществу, в котором фирма IBM уже имела имя и пользовалась ре- путацией, и которые, по крайней мере так представляется при ретроспек- тивном рассмотрении, были готовы к быстрому переходу к персональной вычислительной технике. MS-DOS, конечно, очень много выиграла благода- ря успеху IBM PC - большей частью потому, что фирма IBM поставляла все свои языки программирования и прикладные программы в формате MS-DOS . Но вначале журналисты в рекламной прессе все еще верили в СР/М и ставили под вопрос жизнеспособность новой операционной системы в мире персональных компьютеров, в котором доминировала СР/М-80. Компания Microsoft, между тем, придерживалась уверенности в том, что успех вычислительной машины фирмы IBM или любого другого 16-раз- рядного микрокомпьютера в конечном счете зависел от появления промыш- ленного стандарта для 16-разрядной операционной системы. Разработчики программного обеспечения не могли тратить усилия на разработку прог- раммного обеспечения даже для двух или трех различных операционных систем, а пользователи не могли (или не стали бы) платить разработчи- кам по тем ценам, которые бы они назначили, если бы могли. Более того, пользователи были бы почти наверное возмущены неудобствами, которые доставляет хранение данных в форматах различных операционных систем. Должна была быть одна операционная система, и компания Microsoft хоте- ла, чтобы это была MS-DOS . Компания уже предприняла первый шаг по направлению к стандарту, предпочитая независимые от аппаратных средств проектные решения везде, где это было возможно. Независимость от технических средств означала мобильность, а мобильность означала, что Microsoft может продавать од- ну и ту же версию MS-DOS различным изготовителям вычислительных сис- тем, которые, в свою очередь, могли адаптировать ее к своему собствен- ному оборудованию. Однако, одна только мобильность не могла гарантиро- вать, что система получит широкую поддержку и будет везде принята. Чтобы сделать MS-DOS стандартом, компании Microsoft необходимо было убедить прикладных программистов писать программы для MS-DOS . А в 1981 году разработчики прикладного программного обеспечения были нес- колько приведены в замешательство новой операционной системой. 3.4.1. Операционная система с каким-нибудь другим названием ... Одной из причин замешательства вокруг MS-DOS была неразбериха с ее названиями. Операционная система Тима Патерсона для микропроцессора 8086 вначале продавалась компанией Seattle Computer Products как 86-DOS. После того, как Microsoft купила 86-DOS, некоторое время сох- ранялось ее прежнее название, но к тому времени, когда РС была подго- товлена к выпуску, новая система была готова как MS-DOS. Затем, после того, как IBM PC появилась на рынке, фирма IBM стала называть эту опе- рационную систему IBM Personal Computer DOS, что в рекламной прессе было сокращено до PC-DOS. Версия фирмы IBM содержала некоторые утили- ты, такие как DISKCOPY и DISKCOMP, которые не были включены в MS-DOS, общую версию, лицензии на которую продавались другим разработчикам. Обращая внимание на эти различия, публикации только увеличивали пута- ницу вокруг вопроса о различии между реализациями MS-DOS фирм Microsoft и IBM. Дальнейшие сложности возникли, когда фирма Lifeboat Associates согласилась содействовать распространению MS-DOS, но решила назвать эту операционную систему Software Bus 86. MS-DOS , таким образом, ста- ла одним из продуктов, имевших торговую марку Software Bus. Другим та- ким продуктом был продукт, названный SB-80 и являвшийся версией СР/М-80 фирмы Lifeboat. И наконец, некоторые из компаний по разработке технических сред- ств, одними из первых купивших лицензии на MS-DOS, также хотели ис- пользовать свои собственные названия для этой операционной системы. Таким образом, появились такие дополнительные названия, как COMPAQ-DOS и Z-DOS фирмы Zenith. При наличии такой путаницы названий для продукта, который, как надеялись его разработчики, мог стать промышленным стандартом, фирма Microsoft в конце концов взяла инициативу в свои руки и, как разработ- чик, потребовала, чтобы эта операционная система называлась MS-DOS. Со временем с этим согласились все, кроме компании IBM. 3.5. Разработчики и MS-DOS В самом начале своей карьеры MS-DOS представляла только небольшую часть деловых интересов фирмы Microsoft - BASIC и другие языки прог- раммирования приносили намного больший годовой доход. Кроме того, в течение первых двух лет после появления IBM PC, развитие СР/М-86 и других систем шел почти параллельно с развитием MS-DOS . Так что ком- пания Microsoft ощущала себя в незавидном положении, оказывая поддерж- ку MS-DOS, и в то же время также продавая языки программирования, ко- торые работали под управлением СР/М-86, таким образом делая вклад в развитие программного обеспечения для самого сильного конкурента MS-DOS . При неопределенном исходе в соревновании этих двух систем, неко- торые другие разработчики программного обеспечения предпочитали по- дождать и посмотреть, какой путь изберут разработчики аппаратных сред- ств. Со своей стороны, разработчики технических средств были поставле- ны перед вопросом совместимости операционных систем. Точнее, им нужно было убедиться, что MS-DOS не была "недоделком" - что она могла рабо- тать так же хорошо, как и СР/М-86, в качестве основы для приложений, которые переносились из среды СР/М-80 для использования на 16-разряд- ных вычислительных машинах. Фирма Microsoft подошла к этой проблеме, выделяя четыре взаимос- вязанных момента в дискуссиях с разработчиками технических средств. * Во-первых, одной из целей компании Microsoft при разработке первой версии MS-DOS всегда была совместимость (посредством трансля- ции) программного обеспечения в СР/М-80 и MS-DOS. * Во-вторых, такая трансляция была возможна только для программ- ного обеспечения, написанного на языке ассемблера для микропроцессоров 8080 и Z80; следовательно, ни в MS-DOS , ни в СР/М-86 не могли выпол- няться программы, написанные для других 8-разрядных процессоров, таких как 6800 или 6502. * В-третьих, большое количество прикладных систем было написано на языках программирования высокого уровня, а не на языке ассемблера. * В-четвертых, большинство из этих высокоуровневых языков были продуктами фирмы Microsoft и работали под управлением MS-DOS. Таким образом, даже хотя некоторые с самого начала были уверены, что только СР/М-86 автоматически создаст основу для программного обес- печения, разработанного для СР/М-80, которое будет доступно IBM PC и другим 16-разрядным ЭВМ, компания Microsoft убедила разработчиков тех- нических средств, что MS-DOS является, в действительности , такой же гибкой, как и СР/М-86 по отношению к совместимости с существующим - и соответствующим - программным обеспечением для СР/М-86. Однако, в одной области MS-DOS была поставлена в невыгодное поло- жение, когда фирма Digital Research уговорила нескольких изготовителей технических средств включить в свои машины оба микропроцессора 8080 и 8086. Имея 8-разрядное и 16-разрядной программное обеспечение, исполь- зуемое на одной и той же вычислительной машине, пользователь мог опи- раться на один и тот же формат диска для обоих типов программного обеспечения. Так как в MS-DOS использовался отличный формат диска, СР/М имела преимущество для этих двух-процессорных машин, хотя, на са- мом деле, это, по-видимому, не имело большого значения для выживания СР/М-86 после первого года ее эксплуатации или дальше. Хотя сделать MS-DOS с очевидностью предпочитаемой операционной системой было не так просто, как убедить изготовителей технического обеспечения принять ее, все же список пользователей MS-DOS фирмы Microsoft постоянно рос со времени создания этой операционной системы. Многие разработчики аппаратных средств продолжали предпочитать СР/М-86 по сравнению с MS-DOS, но к концу 1983 года на рынке уже царило техни- ческое превосходство MS-DOS (поддержанной созданием таких программных продуктов, как Lotus 1-2-3). Например, когда компания DEC, долгое вре- мя выжидавшая, решила сделать MS-DOS главной операционной системой на своем персональном компьютере Rainbow, компания в качестве причин сво- его отказа от СР/М приняла во внимание более богатое множество команд MS-DOS и значительно лучшую производительность MS-DOS при работе с дисками. 4. ВЕРСИЯ 2 (1982 - 1983 г.) После выпуска РС-ориентированной версии 1.0, фирма Microsoft про- должала работу по совершенствованию своей операционной системы. Вер- сия 1.1 была передана фирме IBM для установки на усовершенствованной модели РС, выпущенной в 1982 году, и позволяла MS-DOS работать с двус- торонними 320-Кбайтными гибкими дисками. Эта версия, называемая всеми (за исключением фирмы IBM) версией 1.25, была первой версией MS-DOS, передававшейся другим фирмам-разработчикам персональных компьютеров, включая Compaq и Zenith. Однако, даже перед тем, как появились эти промежуточные версии, фирма Microsoft начала планировать разработку следующих версий MS-DOS. При разработке первой версии перед программистами стояли две главные цели: обеспечить возможность выполнения в новой операционной системе программного обеспечения СР/М-80 (посредством перетрансляции) и сохра- нить небольшой размер MS-DOS. У них не было ни времени, ни места для более сложных функций, типичных для разработанной фирмой Microsoft ос- нованной на Unix многопользовательской и многозадачной операционной системы XENIX. Но когда фирма IBM сообщила Microsoft, что следующей базовой моделью РС будет Personal Computer XT с 10-Мбайтным фиксиро- ванным диском, стала реальной возможность создания более крупной, бо- лее мощной версии MS-DOS - приближающейся к идеалу той операционной системы, которую фирма Microsoft представляла себе с самого начала. Фирму Microsoft интересовали три конкретные области: новая иерар- хическая файловая система, инсталлируемые драйверы устройств и некото- рое подобие мультизадачности. Разработки в каждой из этих областей внесли свой вклад в версию 2.0, и все вместе они представляют главные изменения в MS-DOS, сохраняя в то же время совместимость с версией 1.0. 4.1. Файловая система Ответственность за разработку версии 2.0 в основном была возложе- на на Пола Аллена, Марка Збиковски и Аарона Рейнольдса, которые напи- сали (и переписали) большинство из программ версии 2.0. Основной зада- чей проектирования, стоявшей перед разработчиками, как и наиболее оче- видным примером отличия новой версии от версий 1.0, 1.1 и 1.25, бы- ла разработка иерархической файловой системы, предназначенной для уп- равления файлами на фиксированном диске XT. В версии 1.0 был единственный каталог для всех файлов на гибком диске. Эта система работала довольно хорошо на диске ограниченной ем- кости, но на 10-Мбайтном фиксированном диске один каталог мог быстро стать неуправляемо большим и запутанным. В СР/М проблема хранения файлов на внешнем запоминающем устройст- ве большого объема решалась при помощи схемы разбиения, согласно кото- рой фиксированный диск делился на десять пользовательских областей, приравненных к десяти отдельным дисководам гибких дисков. С другой стороны, в операционной системе Unix, которая традиционно работала с более крупными вычислительными системами, использовалась разветвленная иерархическая файловая структура, в которой пользователь может созда- вать каталоги и подкаталоги, чтобы упорядочить файлы и сделать их лег- ко доступными. Такой была система управления файлами, реализованная в XENIX, и разработчики MS-DOS выбрали эту схему для управления файлами на фиксированном диске ХТ. Схема разбиения - первоначальный выбор фирмы IBM - имела ряд пре- имуществ: она была хорошо знакома программистам, имела небольшой раз- мер и была проста в реализации. Многие пользователи малых систем - в частности, разработчики программного обеспечения - были уже знакомы по опыту работы с СР/М со схемой разбиения, хотя и не всем она нравилась. Основным фактором было также время разработки, а программы, необходи- мые для разработки схемы разбиения, имели бы очень мало общего по сравнению с программами, необходимыми для управления иерархической файловой системой. Кроме того, на реализацию схемы разбиения ушло бы меньше времени. Однако, схема разбиения имела два существенных недостатка. Во- первых, ее производительность уменьшалась с ростом объема внешних за- поминающих устройств, а уже в 1982 году фирма Microsoft предвидела значительный рост емкости дисковых запоминающих устройств. Во-вторых, схема разбиения зависит от физического устройства. При изменении раз- мера диска и в программах операционной системы, и в прикладных прог- раммах должны быть изменены либо количество, либо размер областей раз- биения. Для фирмы Microsoft , с ее стремлением к независимости от тех- нических средств, реализация схемы разбиения означала бы шаг в невер- ном направлении. С другой стороны, иерархическая файловая структура могла быть не- зависимой от физических устройств. Диск может разбиваться на области логически, а не физически. И поскольку эти области разбиения (катало- ги) управляются пользователями, то их можно легко создавать и уничто- жать, что позволяет индивидуальному пользователю наилучшим образом оп- ределять организацию файлов на диске. В конце концов, именно иерархическая файловая система была реали- зована в MS-DOS 2.0, и со временем каждый пользователь убедился, что это, вероятно, наилучшее и более гибкое решение задачи поддержки жест- кого диска. Эта файловая система логически согласовывалась с файловой структурой операционной системы XENIX, а также физически согласовыва- лась с методом доступа к файлам, применявшимся в версиях 1.x, и была основана на корневом, или главном, каталоге, под которым пользователь мог создавать систему под-каталогов и под-под-каталогов для управления файлами. Каждый файл в системе идентифицируется путем каталогов, веду- щим к нему, и число подкаталогов было ограничено только длиной имени пути, которая не должна превосходить 64 символа. В этой файловой структуре все подкаталоги и имя файла в имени пу- ти отделялись друг от друга символами обратной косой черты (""), что представляет единственное отличие систем иерархических файлов в XENIX и MS-DOS. В XENIX в качестве разделителя используется прямая косая черта ("/"), но в версиях 1.x MS-DOS , по аналогии с традицией опера- ционных систем фирмы DEC, прямая косая уже использовалась для указания ключей в командной строке , поэтому фирма Microsoft, по требованию фирмы IBM, решила использовать обратную косую в качестве такого разде- лителя. Хотя использование символа обратной косой черты не создавало никаких проблем, кроме тех клавиатур, на которых нет обратной косой, это решение внесло несогласованность между MS-DOS и существующими Unix-подобными операционными системами. И хотя фирма Microsoft разре- шила проблему с клавиатурой, дав возможность пользователю заменять символ ключа с косой на апостроф, но само это решение создало проблемы совместимости для тех программистов, которые хотели обмениваться ко- мандными файлами. Еще одно крупное изменение в системе управления файлами относи- лось к новой структуре каталога. Чтобы более полно использовать преи- мущества иерархической файловой системы, фирма Microsoft должна была добавить новый способ обращения к файловым служебным функциям. В версиях 1.x MS-DOS используется структура, аналогичная исполь- зуемой в СР/М и называемая блоками управления файлами (file control blocks - FCBs), чтобы обеспечить совместимость с более старыми прог- раммами для СР/М-80. Блоки FCB содержали всю необходимую информацию о размере и размещении файла, но они не позволяли пользователю описывать файл в другом каталоге. Таким образом, версия 2.0 MS-DOS нуждалась в дополнительных средствах доступа к файлам посредством указателей (handles), или дескрипторов, которые позволяли бы работать с файлами в различных каталогах. Согласно этому дополнительному шагу по направлению к логической независимости от устройств, MS-DOS возвращает дескриптор, как только MS-DOS-программа открывает файл. Все дальнейшие действия с файлом осу- ществляются только с этим дескриптором. В MS-DOS были сделаны все не- обходимые корректировки внутренней структуры - отличной от FCB - так что программа никогда не должна была работать непосредственно с инфор- мацией о размещении файла, хранящейся в памяти. Более того, даже если в последующих версиях MS-DOS стуктура внутренних модулей управления будет изменена, программы не придется переписывать - единственной не- обходимой ссылкой будет дескриптор файла, а это не изменится. Передача внутренних управляющих модулей под надзор MS-DOS и заме- на блоков FCB дескрипторами также позволили MS-DOS переназначить ввод и вывод программ. Была создана системная функция, которая дала возмож- ность MS-DOS перенаправлять операцию чтения или записи, ассоциирован- ную с одним дескриптором, на файл или устройство, связанное с другим декриптором. Эта возможность была использована в COMMAND.COM, чтобы позволить переадресовать выходные данные, направлявшиеся в файл, на некоторое устройство, такое как печатающее устройство, или передать их другой программе. Это также позволило осуществлять системную очистку (cleanup) по окончании программы. 4.2. Инсталлируемые драйверы устройств В то время, когда фирма Microsoft начала разработку версии 2.0 MS-DOS, компания также прекрасно понимала, что многие периферийные ус- тройства различных изготовителей работают совместно очень плохо. Каж- дый изготовитель включал программную поддержку своих технических сред- ств в MS-DOS своим собственным способом, и если два устройства различ- ных разработчиков подключились в компьютер одновременно, они часто друг другу мешали или вообще не могли работать. Одной из отличительных особенностей подхода фирмы IBM к разработ- ке РС была открытая архитектура, что означало, что пользователи могут просто вставить новые платы в компьютер, как только к вычислительной системе будут добавлены новые устройства ввода/вывода, такие как фик- сированные диски или печатающие устройства. К сожалению, версия 1.0 MS-DOS не имела соответствующей заложенной в ней открытой архитектуры - все программы, позволявшие операционной системе работать с техничес- кими средствами, находились в BIOS. Если независимый разработчик тех- нических средств хотел создать оборудование для использования его с операционной системой разработчика компьютера, то он должен был либо полностью переписать драйверы устройств, либо написать сложную утилиту чтения существующих драйверов, их изменения и добавления фрагментов программ, чтобы обеспечить работу нового устройства и чтобы создать работающее множество драйверов. Если пользователь подключает более, чем одно устройство, то эти вставки в программы будут противоречить друг другу. Более того, каждый раз, когда разработчик компьютера будет обновлять свою версию MS-DOS, пришлось бы пересматривать и эти встав- ки. К тому времени, когда была начата работа над версией 2.0, разра- ботчики MS-DOS понимали, что возможность инсталляции любого драйвера устройств во время работы была жизненно необходимой. Они реализовали инсталлируемые драйверы устройств, сделав драйверы более модульными. Как и FAT, IO.SYS (IBMBIO.COM в PC-DOS) стала, по сути, списком со ссылками - на то время, драйверов устройств - который мог быть расши- рен при помощи команд в файле CONFIG.SYS, находящемся на системном загрузочном диске. Разработчик мог теперь написать драйвер устройства, который пользователь мог инсталлировать во время работы, включив его в файл CONFIF.SYS. Затем MS-DOS добавила бы этот драйвер устройства к ссылочному списку. Кроме того, возможность инсталлировать драйверы устройств сделала возможной замену ранее инсталлированных драйверов - например, драйвера консоли ANSI.SYS, обеспечивающего стандартные коды смены алфавита ANSI для позиционирования курсора и управления экраном. 4.3. Откачка данных на печать По просьбе фирмы IBM, версия 2.0 MS-DOS также содержала не ука- занную в документации возможность выполнять элементарную фоновую обра- ботку - промежуточное решение при растущем осознании потенциальной многозадачности. Фоновый вывод данных на печать был существенным для удовлетворе- ния потребностей большинства пользователей в большинстве ситуаций, так что программа вывода данных на печать, PRINT.COM, была создана, чтобы работать всякий раз, когда MS-DOS не выполняет больше никакой работы. Когда обратившаяся к ней прикладная программа становится активной, PRINT.COM прерывается до следующего перерыва в ее работе. Несмотря на ограниченность и чрезвычайную сложность, фоновая обработка такого типа использовалась в ряде приложений, например, таких как SideKick. 4.4. Другие изменения в новой версии MS-DOS Главными проектными решениями в версии 2.0 было введение иерархи- ческой файловой структуры, инсталлируемых драйверов устройств и фоно- вого вывода данных на печать. Но в ней также были и десятки более мел- ких изменений. Например, для фиксированного диска необходимо было модифицировать программу автоматической регистрации (logging) дисков. Эта модификация означала, что MS-DOS должна была обращаться к диску чаще, и поэтому в результате доступ к файлам стал значительно медленнее. В попытке найти решение этой проблемы, Крис Петерс пришел к такому рассуждению: если MS-DOS только что проверила диски, то требуется некоторое минимальное время, необходимое пользователю, чтобы физически изменить диск. Если это минимальное время не прошло, то текущая информация о диске в опе- ративной памяти - будь то для фиксированного диска или для гибкого - является, вероятно, все еще правильной. Петерс выяснил, что самое минимальное время, за которое кто-либо может физически изменить диски, даже если диски заняты в процессе ра- боты, это время около двух секунд. Исходя из этого наблюдения , он заставил MS-DOS проверять, сколько времени прошло с момента последнего доступа к диску. Если прошло менее двух секунд, MS-DOS считает, что новый диск не вставлен и информация о диске в оперативной памяти все еще правильная. Благодаря этой маленькой уловке скорость обработки файлов в версии 2.0 MS-DOS значительно возросла. Версия 2.0 была выпущена в марте 1983 года и являлась результатом работы удивительно маленького коллектива шести разработчиков, включав- шего Петерса, Мани Уллоа и Нэнси Пэннерс в добавление к Аллену, Зби- ковски и Рейнольдсу. Несмотря на сложность своих новых функций, прог- раммы версии 2.0 занимали объем всего лишь в 24 Кбайта. Хотя она сох- ранила свою совместимость с версиями 1.х, это была на самом деле зна- чительно отличавшаяся от них операционная система. В течение шести ме- сяцев после ее выпуска, версия 2.0 получила общее признание. Более то- го, распространенные прикладные программы, такие как Lotus 1-2-3, пользовались преимуществами этой новой версии MS-DOS и таким образом помогали обеспечить ее будущее как промышленного стандарта для микроп- роцессора 8086. 4.4.1. Версии 2.1 и 2.25 Мир, в который вошла версия 2.0 MS-DOS, значительно отличался от того, в котором дебютировала версия 1.0. Когда фирма IBM выпустила свою первую модель персонального компьютера РС, рынок микрокомпьютеров был еще несформировавшимся - если не в объеме, то по крайней мере в том, кто или что будет доминировать в этой области. Через полтора го- да, когда на сцене появилась IBM PC/XT, ситуация на рынке была уже бо- лее известной. Значительное влияние на нее оказывала, фактически, сама фирма IBM. Но на рынке также было много персональных компьютеров, на которых работала MS-DOS, таких как Tandy 2000 и HP 150 фирмы Hewlett Packard, которые были несовместимы на аппаратном уровне с персональны- ми компьютерами фирмы IBM, но разработчики новых ЭВМ знали, что IBM - это сила, которую нельзя игнорировать, и многие предпочли конкуриро- вать с IBM PC, эмулируя ее. Разработчики программного обеспечения так- же выиграли от развития микрокомпьютеров, так как они были уверены, что их программы точно найдут свое место на огромном рынке MS-DOS-про- дуктов. В такой обстановке представления о программном обеспечении для СР/М как о существующей базе программирования отходили на задний план, по мере того, как разработчики все более принимали во внимание быстро развивающийся рынок персональных компьютеров и MS-DOS, быстро завоевы- вавшей свои позиции как промышленный стандарт. Теперь, когда препятст- вий для распространения MS-DOS не было, фирма Microsoft оказалась пе- ред новой задачей: поддержкой созданного ею стандарта. Таким образом, MS-DOS должна была предоставлять много во возможностей различным пользо- вателям. У фирмы IBM были свои требования; другие разработчики техни- ческих средств выдвигали свои требования. И иногда эти требования были противоречивы. 4.5. Разработчики технических средств Когда была выпущена версия 2.0, фирма IBM уже планировала выпуск своего персонального компьютера PCjr. Предполагалось, что PCjr будет иметь возможность выполнять программы, находящиеся в блоках ПЗУ (ROM cartridges), и, вдобавок к использованию 5,25-дюймового дисковода по- ловинной высоты, с ней будет реализована несколько отличная архитекту- ра контроллера диска. Учитывая эти отличия от персональных компьютеров серии стандартных PC, фирма IBM хотела иметь версию 2.1 MS-DOS , не- посредственную модификацию для этой новой машины. В дальнейшем IBM также планировала создание более быстродействую- щей, более мощной версии РС с 20-Мбайтным фиксированным диском. Эти планы означали, что фирма Microsoft должна опять пересмотреть свою систему управления файлами, так как больший объем памяти 20-Мбайтного диска превышал ограничения по размерам для таблицы размещения файлов в том виде, в каком она работала в версии 2.0. Однако, основное усовершенствование, которое фирма IBM хотела ви- деть в следующей новой версии MS-DOS была возможность работы в вычис- лительных сетях. Фирма Microsoft предпочла бы разработку средств муль- тизадачности как следующий этап разработки MS-DOS, но IBM уже занима- лась разработкой сетевого адаптера (Network Adapter) IBM PC, платы с микропроцессором 80188, подключаемой к персональным компьютерам и предназначенной для управления коммуникациями. Так что как только была выпущена версия 2.0, разработчики MS-DOS, опять возглавляемые Збиковс- ки и Рейнольдсом, начали работу над сетевой версией (3.0) этой опера- ционной системы. 4.6. Между тем . . . В первые годы после выпуска IBM PC и версии 1.0 MS-DOS, междуна- родный рынок MS-DOS не был значительным. Вначале IBM не продавала свой Personal Computer в Европе, так что фирма Microsoft была вынуждена са- ма способствовать распространению MS-DOS. В 1982 году компания получи- ла в Европе значительное преимущество по сравнению с СР/М, заключив договор с фирмой Victor, компанией по разработке программного обеспе- чения, дела которой в Европе шли очень успешно и которая ранее уже приобрела лицензию на СР-М/86. Работая в тесном сотрудничестве с Victor, фирма Microsoft обеспечила специальную поддержку разработки ее графических адаптеров и со временем убедила эту компанию поставлять ее продукты только под управлением МS-DOS. В Японии наиболее распространенными вычислительными машинами были персональные компьютеры, оснащенные микропроцессором Z80, и в силу на- личия огромной базы 8-разрядных машин в стране, 16-разрядные компьюте- ры не получили поддержки. Фирма Mitsubishi, однако, предлагала на ры- нок 16-разрядный персональный компьютер. Хотя первоначально фирма Mitsubishi выбрала в качестве операционной системы СР/М-86, специалис- ты фирмы Microsoft помогли ей получить Multiplan и FORTRAN, работающие под управлением СР/М-86, и со временем завоевали у этой фирмы доверие и поддержку для MS-DOS. В области программного обеспечения, в то время, когда шла разра- ботка версий 2.х MS-DOS, другие покупатели фирмы Microsoft начали бо- лее громко говорить о своих потребностях. Некоторым пользователям нуж- ны были сетевые средства, что придавало вес требованиям фирмы IBM, но более насущной потребностью, необходимой многим - но не учитывавшейся в то время фирмой IBM - была поддержка международных программных и технических продуктов. В особенности, таким компаниям нужна была вер- сия MS-DOS, которая могла бы продаваться в других странах - версия MS-DOS, которая бы выдавала сообщения на других языках и была адапти- рована к специфическим для данной страны соглашениям, таким как форма- ты даты и времени. Со своей стороны, фирма Microsoft хотела интернационализировать MS-DOS, так что разработчики MS-DOS, модифицируя операционную систему для работы на PCjr, добавили также ряд функций и команду COUNTRY, ко- торые позволяли пользователям устанавливать форматы ввода даты и вре- мени и другие зависимые от национальных условий параметры в файле CONFIG.SYS. Почти в то же самое время возникло еще одно требование межнацио- нального характера. Японский рынок MS-DOS рос, и возник вопрос поддер- жки 7 000 символов (идеограмм) алфавита Kanji. Трудность с Kanji сос- тояла в том, что для него требовались 2-байтные символы. Для английс- кого и большинства европейских наборов символов 1 байт соответствовал одному символу. Однако, для японских символов иногда используется один байт, а иногда два. Такая изменчивость создает проблемы при синтакси- ческом анализе, и в результате MS-DOS должна была быть модифицирована так, чтобы синтаксический анализ строки производился с начала, а не с конца по одному символу за раз. Такая поддержка форматов отдельных стран и алфавита Kanji появи- лась в версии 2.01 MS-DOS. Фирма IBM не хотела иметь такую версию, по- этому программное обеспечение для PCjr, разработанное Збиковски, Рей- нольдсом, Уллоа и Эриком Эвансом возникло отдельно, как версия 2.1, которая предназначалась только для IBM и не содержала модификаций, сделанных для международной версии MS-DOS. 4.6.1. Различные заказчики, различные версии Еще при разработке версии 1.25 фирма Microsoft оказалась перед проблемой, пытаясь удовлетворить потребности тех разработчиков собст- венных технических средств, которые хотели иметь такую же версию MS-DOS, как и IBM. Некоторые, такие как COMPAQ, в своих аппаратных средствах обеспечивали 100%-ную совместимость с IBM. Для них любое различие между их версией и версией для IBM влекло возможность несов- местимости. Однако, удовлетворить эти требования было трудно, и это не было сделано вплоть до выпуска версии 3.1, когда фирма Microsoft ока- залась в состоянии сделать такую систему, о которой другие разработчи- ки технических средств сказали, что она идентична с версией для IBM. Для того, чтобы удовлетворить эти требования разработчиков техни- ческих средств, фирма фирма Microsoft скомбинировала версии 2.1 и 2.01, чтобы создать версию 2.11. Хотя IBM не приняла ее из-за интерна- ционализированных программ, версия 2.11 стала стандартной версией для всей заказчиков фирмы, кроме IBM. Версия 2.11 продавалась во всем мире и была переведена примерно на десять различных языков. Две другие про- межуточные версии обеспечивали поддержку для алфавита Hangeul (корейс- кого набора символов) и китайского Kanji. 4.7. Разработка прикладного программного обеспече- ния После выпуска версии 2.0, фирма Microsoft также получила важную для себя - и трудно дающуюся - высокую оценку и поддержку тех, кто разрабатывал прикладное программное обеспечение для MS-DOS . Разработчики программного обеспечения следят за совместимостью на низком уровне, а также за высокоуровневой совместимостью. Но несмотря на это, они иногда используют программистские приемы, которые не могут гарантировать совместимость. Когда это происходило, а получавшиеся в результате программы работали успешно, обеспечение совместимости воз- лагалось на фирму Microsoft. Например, так как была опубликована информация о содержании BIOS и интерфейса ПЗУ, разработчики программного обеспечения могли (и часто делали это) работать непосредственно с аппаратными средствами, чтобы повысить скорость обработки. Это означало выполнение некоторых опера- торов в обход операционной системы. Однако, решив работать на самом низком уровне, такие разработчики утрачивали защиту от изменений аппа- ратных средств, обеспечивавшуюся операционной системой. Таким образом, когда изменения вносились в аппаратные средства, их программы либо не работали, либо не могли работать согласованно с другими приложениями. Другой проблемой при разработке программного обеспечения было все еще остающееся требование совместимости с СР/М. Например, в СР/М, что- бы запросить некоторую функцию, программист должен обращаться к фикси- рованному адресу низкоуровневой памяти, а в MS-DOS программист исполь- зует служебные средства операционной системы, осуществляющие прерыва- ние программного обеспечения. Чтобы обеспечить поддержку более старого программного обеспечения, первая версия MS-DOS позволяла программам обращаться к функциям другим методом. Одной из СР/М-программ, поддер- живавшихся таким образом, был очень распространенный пакет WordStar. Поскольку фирма Microsoft не вносила изменений в MS-DOS, которые сде- лали бы невозможным выполнение такой широко используемой программы, каждая новая версия MS-DOS продолжала поддерживать способ обращений, подобный СР/М. Более распространенным происходившим от СР/М методом было обраще- ние к файлам и управление записями типа FCB (file control block - блок управления файлом). В версиях 1.х MS-DOS использовался, как и в СР/М, исключительно тип обращений FCB. В версии 2.0 были введены более эф- фективные и гибкие средства обращения по дескриптору (handle), но фир- ма Microsoft не могла просто отказаться от старого типа обращений FCB, так как он использовался во многих распространенных программах. Факти- чески, он используется в некоторых из языков программирования, разра- ботанных самой фирмой Microsoft. Таким образом, MS-DOS должна была поддерживать оба типа обращений в версиях 2.х. Однако, чтобы поощрить использование новых обращений по дескрипторам, фирма Microsoft сделала несложным для пользователей MS-DOS возможность наращивать ее до версии 2.0. Кроме того, компания убедила фирму IBM, что необходимо заказать версию 2.0 для РС/ХТ и также поощрила разработчиков программного обес- печения, чтобы они требовали 2.0 для своих приложений. Во-первых, и разработчики программного обеспечения, и поставщики технических средств с неохотой заказывали 2.0, поскольку их беспокоило то, что возникнут проблемы с большим количеством уже поставленных сис- тем версии 1.0 - заказ версии 2.0 означал поддержку обоих типов обра- щений. Прикладные программы также нуждались в возможности проверки то- го, с какой версией операционной системы работает пользователь. Для версий 1.х программы должны использовать FCB-обращения, а для версий 2.х они будут использовать дескрипторы файлов, чтобы более полно реа- лизовать гибкость MS-DOS. Из всего вышесказанного следует, что это был сложный период пере- хода, но к тому времени, когда фирма Microsoft начала работать над версией 3.0 и поддержкой фиксированного диска IBM емкостью 20 Мбайт, стало очевидным, что эти перемены были в интересах каждого. 5. ВЕРСИЯ 3 (1983 - 1984) Вопросы, которые начали возникать, когда фирма Microsoft присту- пила к разработке версии 3.0, операционной системы MS-DOS для работы в вычислительных сетях, связаны с проблемами совместимости, значительно возросшими по сравнению с теми, которые встречались ранее. Во-первых, средства работы в вычислительных сетях, с или без средств мультизадачности, требуют такого уровня согласованности и сов- местимости программ, который никогда ранее не был нужен при разработке более ранних версий MS-DOS. Как описывал Марк Збиковски, один из глав- ных разработчиков этого проекта, "между версиями 2.1 и 3.0 был очень большой период времени - почти полтора года. В течение этого периода мы были уверены, что понимаем все проблемы, связанные с преобразовани- ем MS-DOS в сетевой продукт. Но по прошествии времени мы осознали, что не понимаем полностью всего, либо связанного с проблемами совместимос- ти, либо с операционной системой . Мы очень хорошо знали, как MS-DOS работает в однозадачной среде, но по мере продвижения к новой вычисли- тельной среде мы обнаружили места, в которых она была несовершенной". Большое разнообразие программ и программных подходов, поддержива- емых MS-DOS, оказалось со временем одним из наибольших препятствий при разработке сложной сетевой системы и, в последующем , в добавлении функций многозадачности. Далее, к тому времени, когда фирма Microsoft начала работать над версией 3.0, стиль программирования коллектива разработчиков MS-DOS значительно изменился. Этот коллектив ставался по-прежнему небольшим, с ядром только из пяти человек: Збиковски, Рейнольдс, Петерс, Эванс и Марк Бебис. Но на программное обеспечение MS-DOS в целях обеспечения управляемости и обозримости системы стали переноситься методы, домини- ровавшие в программировании для больших вычислительных систем. Теперь желание использовать программистские уловки для оптимизации скорости вычислений должно было сдерживаться необходимостью обеспечения ясности и простоты сопровождения. И небольшим пакетом компактно написанных программ, каким были ранние версии MS-DOS, по этим причинам пришлось пожертвовать. 5.1. Версия 3.0 Как уже было сказано, работа над версией 3.0 MS-DOS оказалась долгой и трудоемкой. В течение полутора лет фирма Microsoft боролась с проблемами программной несовместимости, управления удаленными файлами, логической независимости устройств на сетевом уровне. Даже тогда, ког- да фирма IBM была готова аннонсировать создание своей новой вычисли- тельной машины Personal Computer AT, сетевое программное обеспечение для MS-DOS не было еще окончательно готово, поэтому в августе 1984 го- да фирма Microsoft выпустила версию 3.0 для IBM без сетевого программ- ного обеспечения. В версии 3.0 поддерживались более крупный фиксированный диск АТ, новый таймер (clock) CMOS и большие по объему 1,2-Мбайтные гибкие дис- ки. В ней также обеспечивалась поддержка некоторых межнациональных сервисных средств, включавшихся ранее в версии 2.01 и 2.11. Эти воз- можности предоставлялись как версия 3.05 MS-DOS другим компаниям - партнерам фирмы Microsoft, разрабатывавшим собственные технические средства. Но версия 3.0 не была простым расширением версии 2.0. Закладывая основу для средств сетевого взаимодействия, разработчики MS-DOS пол- ностью перепроектировали и переписали ядро DOS. Отличавшаяся сама по себе от версии 1.0, версия 2.0 была надстро- ена над той же самой структурой. Например, если в запросах к файлам в MS-DOS 1.0 использовались блоки управления файлами (FCB), то в версии 2.0 использовались дескрипторы файлов. Однако, при обращении к деск- рипторам файлов в версии 2.0 просто производился синтаксический анализ имени пути и затем, таким же образом, как и в версии 1.0, использова- лись находившиеся на более низком уровне обращения к FCB. Переадреса- ция ввода и вывода в версии 2.0 еще больше усложнила запросы файловой системы. Когда в программе использовалось одно из совместимых с СР/М обращений к символьному вводу/выводу, MS-DOS 2.0 вначале открывала дескриптор файла, а затем возвращала его обратно на более низкий уро- вень в обращение к FCB . В версии 3.0 эта избыточность была устранена удалением старых программ ввода/вывода с помощью FCB, использовавшихся в версиях 1 и 2, и заменой их стандартным набором обращений ввода/вы- вода, к которым могли обращаться непосредственно как FCB-обращения, так и обращения посредством дескрипторов. Обращения, похожие на вид на СР/М-совместимые обращения к символьному вводу/выводу, были включены как часть набора обращений к дескрипторам. В результате этой реструк- туризации, эти обращения выполнялись в версии 3.0 значительно быстрее, чем в версии 2.0. Однако, более важным, чем удаление неэффективных программ, был тот факт, что новая структура позволяла проще обрабатывать сетевые запросы в рамках модели ISO - взаимосвязей открытой системы (Open System Interconnect model) - которую фирма Microsoft использовала для организации сетевого взаимодействия. Модель ISO описывает ряд уровней протоколов, от интерфейсов между прикладными программами на самом вер- хнем уровне и до физических связей - подключаемых в сеть - на самом нижнем уровне. Посередине находится транспортный уровень, который уп- равляет реальной передачей данных. Уровни, лежащие выше транспортного, подлежат ведению операционной системы, а уровни, находящиеся ниже транспортного, традиционно относятся к области сетевого программного или аппаратного обеспечения. В сети IBM PC транспортный уровень и обслуживающие функции управ- лялиь платой сетевого адаптера IBM (Network Adapter card), и задачей MS-DOS было поддерживать эти аппаратные средства. Однако, для других разработчиков персональных компьютеров, являвшихся заказчиками прог- раммного обеспечения фирмы Microsoft, компания должна была обеспечить поддержку и транспортного уровня, и обслуживающих (серверных) функций своими программными средствами. Хотя в версии 3.0 еще не предоставля- лось такое сетевое программное обеспечение общего назначения, в ней была обеспечена базовая поддержка для сетевого аппаратного обеспечения фирмы IBM. Средства поддержки технических средств IBM состояли из программ переадресации (redirector) и разделения (sharer). При разработке сете- вых средств MS-DOS был использован подход, согласно которому маршрут удаленным запросам прокладывала программа переадресации, которая могла взаимодействовать с транспортным уровнем сети. Транспортный уровень был составлен из драйверов устройств, которые могли осуществлять на- дежную передачу данных из одной части сети в другую. Перед тем, как обращение посылалось в наново спроектированную низкоуровневую програм- му ввода/вывода файлов, операционная система определяла, является ли обращение локальным или удаленным. Локальное обращение выполнялось при помощи локальной программы ввода/вывода файлов, а удаленное обращение должно было пройти через программу переадресации, которая, работая с операционной системой, выявила бы ресурсы на удаленной ЭВМ, если они были локальными. 5.2. Версия 3.1 (1984) Интерфейсы программ переадресации и разделения вместе с платой сетевого адаптера IBM уже были помещены в версию 3.0, когда она была передана фирме IBM, но сама программа переадресации еще не была гото- ва. В версии 3.1, законченной Збиковски и Рейнольдсом и выпущенной на три месяца позже, эти средства сетевой поддержки были готовы и могли поставляться пользователям сетевых плат, выпускаемых другими фирмами, а не IBM, в виде Microsoft Networks. Microsoft Networks была спроектирована на основе концепции "сер- висных средств" и "потребителей" ('services' and 'consumers'). Сервис- ные средства обеспечивались файловым сервером (обслуживающей програм- мой), который был частью прикладного программного обеспечения Networks и работал на компьютере, предназначенном для этой цели. Потребителями были программы, находившиеся на различных ЭВМ вычислительной сети. Запросы на информацию передавались на высоком уровне файловому серве- ру; затем обязанностью файлового сервера было определить, где на диске должна быть найдена эта информация. Запрашивающие программы - потреби- тели - не должны были знать что-либо об удаленной машине, даже то, ка- кой на ней использовался тип файловой системы. Такая возможность передавать запросы высокого уровня удаленному серверу, без необходимости знать подробности файловой структуры серве- ра, позволила создать еще один уровень обобщения в системе. В MS-DOS 3.1 в одной и той же сети можно получить доступ к файловым системам различного типа. Стало возможным, например, получать доступ в сети к вычислительной машине с операционной системой XENIX из машины с опера- ционной системой MS-DOS и читать данные из файлов XENIX. Мicrosoft Networks была спроектирована так, чтобы быть независи- мой от технических средств. Хотя разнообразие классов программ, кото- рые могли бы пользоваться ее структурами, было главной проблемой при разработке сетевой системы, которая была бы "прозрачной" для пользова- теля. При оценке этого разнообразия, фирма Microsoft идентифицировала три типа программ: - во-первых, совместимые с MS-DOS программы. В них используется только документированный метод прерываний программного обеспечения для обслуживания запросов операционной системой, и они работают на любой вычислительной машине с операционной системой MS-DOS без каких-либо сложностей; - во-вторых, основывавшиеся на MS-DOS программы. Они работают на совместимых с IBM компьютерах, но не обязательно на всех MS-DOS-маши- нах; - и в третьих - программы, в которых используются недокументиро- ванные возможности MS-DOS или те, которые адресуются непосредственно к аппаратным средствам. Обычно эти программы имеют самую лучшую произво- дительность, но они настолько же трудны в сопровождении. Исходя из этого фирма Microsoft официально поддерживала создание MS-DOS-совместимых программ для использования в сети. 5.2.1. Разработка средств вычислительных сетей Для упрощения управления файлами в вычислительной сети в версии 3.0 был изменен модуль доступа к файлам, но это не решило всех проб- лем. Например, MS-DOS по-прежнему нуждалась в обработке запросов к блокам управления файлами (FCB) из программ, в которых они использова- лись, но во многих программах FCB обычно открываются, но никогда не закрываются. Чтобы решить эту проблему фирма Microsoft ввела в версию 3.1 кэш-буфер FCB с условием, что только четыре блока управления фай- лами могут быть открыты одновременно. Если будет открыт пятый блок уп- равления файлом, то последний из недавно использовавшихся блоков будет автоматически закрыт и освобожден. Кроме того, в файл CONFIG.SYS была добавлена команда FCBS, чтобы позволить пользователю или администрато- ру сети управлять максимальным количеством блоков управления файлами, которые могут быть открыты одновременно, и предохранить некоторый из FCB от автоматического закрытия. В общем, логическая независимость от устройств, которая была целью при разработке MS-DOS, приобрела новое значение - и создала но- вые проблемы - в условиях работы в вычислительной сети. Одна из проб- лем связана с подключением в сеть печатающих устройств. Вообще, в та- ких случаях сеть используется, чтобы позволить нескольким пользовате- лям одновременно работать с одним печатающим устройством. В сеть прос- то внести программу, которая будет открывать принтер, выводить на него данные и опять закрывать его. Однако, некоторые программы будут пы- татьбся использовать непосредственный интерфейс с BIOS IBM, чтобы по- лучить доступ к печатающему устройству. Чтобы обрабатывать эту ситуа- цию, разработчики фирмы Microsoft должны были разрабатывать для MS-DOS способ перехвата таких обращений к BIOS и фильтрации тех, которые сер- вер не смог обработать. Когда эта работа была сделана, версия 3.1 име- ла возможность "прозрачно" обрабатывать в сети большинство типов обра- щений и вывода на печатающие устройства. 5.3. Версия 3.2 (1986) В январе 1986 года фирма Microsoft выпустила еще одну версию MS-DOS, версию 3.2, в которой осуществлялась поддержка 3,5-дюймовых гибких дисков. Кроме того, в версии 3.2 функция форматирования устрой- ств была перенесена из служебной программы FORMAT в драйверы устрой- ств, чем была устранена необходимость в специальной, зависимой от ап- паратных средств программе, использовавшейся в добавление к драйверу устройства. Эта версия включала простой драйвер устанавливаемого блоч- ного устройства и, в конечном итоге, была полезна пользователям и раз- работчикам IBM-совместимых компьютеров тем, что содержала основные аналоги (копии) MS-DOS-программ для повышения совместимости с IBM PC. 5.3.1. В будущем С момента своего появления в 1981 году операционная система MS-DOS заняла и удерживает завидные позиции на микрокомпьютерном рын- ке. Она не только "научила" миллионы персональных компьютеров "ду- мать", она также научила миллионы людей работать с компьютерами. Мно- гие очень опытные пользователи вычислительных машин могут отсчитывать свое знакомство с персональными компьютерами от исходной модели IBM PC и версии 1.0 MS-DOS. Командный интерфейс MS-DOS удобен для пользовате- лей, а файловая структура MS-DOS, тем или иным образом, была для них чем-то знакома. Фирма Microsoft утверждает, что в ближайшем обозримом будущем MS-DOS будет продолжать развиваться и расти, изменяясь так, как она это делала ранее, чтобы удовлетворять потребностям миллионов пользова- телей. На более длительный срок, MS-DOS, результат работы удивительно маленькой группе высококвалифицированных специалистов , будет, несом- ненно, оставаться промышленным стандартом до тех пор, пока на рынок будут поступать персональные компьютеры, оснащенные микропроцессором 8086 (и до некоторой степени, оснащенные микропроцессором 80286). Ис- тория MS-DOS будет, несомненно, даже длиннее. Эта операционная система заслужила свое место в истории микрокомпьютеров. Джоан Вудкок Р А З Д Е Л II П Р О Г Р А М М И Р О В А Н И Е В С Р Е Д Е MS-DOS ЧАСТЬ А. Структура MS-DOS Глава 1. Введение в MS-DOS Операционная система представляет собой набор управляющих прог- рамм, которые руководят и управляют работой компьютера. Вообще опера- ционная система обеспечивает: - управление памятью; - управление вычислительным процессом; - секретность; - взаимодействие пользователя с компьютером. Существующие операционные системы для микрокомпьютеров делятся на три главные категории: управляющие программы, записанные в ПЗУ (ROM-мониторы), традиционные операционные системы и операционные сре- ды. Основные характеристики этих трех категорий перечислены в табли- це 1.1. Таблица 1-1. Характеристики трех основных типов операционных систем ----------------------------------------------------------------------- ROM- Традиционная Операционные монитор операционная среды система ----------------------------------------------------------------------- Сложность Низкая Средняя Высокая Установка Аппаратная BIOS Операционная система Поставка на ПЗУ Диск Диск Программное обеспечение ПЗУ Диск Диск на Поддержка внешних устройств Физическая Логическая Логическая Доступ к Секторный Файловая Файловая диску система система Пример PC ROM BIOS MS-DOS Microsoft Windows --------------------------------------------------------------------- ROM-монитор - это простейший тип операционной системы. Он разра- ботан для специфической конфигурации аппаратных средств и предоставля ет программе базисный (а часто и прямой) метод доступа к периферийным устройствам, присоединенным к компьютеру. Программы, работающие с ROM-монитором, часто используются для специализированных приложений, таких, как управление микроволновой печью или управление работой дви- гателя автомобиля. Традиционная микрокомпьютерная операционная система создана на основе лучшего, что было создано в ROM-мониторах - BIOS (базисная сис- тема ввода/вывода), и обеспечивает дополнительные возможности, та- кие, как файловая система и логический доступ к периферии. (Логичес- кий доступ к периферии позволяет писать и выполнять прикладные прог- раммы в аппаратно-независимой манере). Традиционная операционная сис- тема также хранит программы в файлах на периферийных запоминающих ус- тройствах и по требованию загружает их в память для выполнения. MS-DOS - это традиционная операционная система. Операционная среда разрабатывалась как надстройка традиционной операционной системы. Операционная среда обеспечивает дополнительные сервисные возможности, такие как главное меню и поддержка форм, кото- рые упрощают функционирование программ и делают пользовательский ин- терфейс более последовательным. Microsoft Windows является операцион- ной средой. 1. Системные компоненты MS-DOS Дисковая операционная система фирмы Microsoft - MS-DOS, является традиционной микрокомпьютерной операционной системой, которая состоит из пяти больших компонент: * Загрузчик операционной системы * BIOS MS-DOS * Ядро MS-DOS * Командный процессор * Вспомогательные обслуживающие программы Каждая из этих компонент кратко описана ниже.См.:ПРОГРАММИРОВАНИЕ В СРЕДЕ MS-DOS: Структура MS-DOS: Компоненты MS-DOS. 1.1. Загрузчик операционной системы Загрузчик операционной системы устанавливает операционную систему с диска в оперативную память. Полный процесс загрузки, называемый начальной загрузкой (дословно - bootstrapping - шнурование ботинок), часто сложен и может вовлекать в "работу" несколько загрузчиков. (Термин bootstrapping вошел в оби- ход, потому что каждый уже загруженный уровень системы "подтягивает" следующую часть системы, все равно как зашнуровывание ботинка). Напри- мер, в большинстве микрокомпьютерных разработок, основанных на стан- дартах MS-DOS, загрузчик, записанный в ПЗУ, являющийся первой исполня- емой микрокомпьютером программой во время включения компьютера или при перезагрузке, считывает дисковый начальный загрузчик из первого (boot) сектора диска первоначальной загрузки и исполняет его. Дисковый на- чальный загрузчик, в свою очередь, считывает основную порцию MS-DOS - MSDOS.SYS и IO.SYS (IBMDOS.COM и IBMBIO.COM для PC-DOS) - с последова- тельных дисковых файлов в память. Затем специальный модуль в MSDOS.SYS - SYSINIT - инициализирует таблицы и буферы MS-DOS и сам удаляется. См.: ПРОГРАММИРОВАНИЕ В СРЕДЕ MS-DOS: Структура MS-DOS: Запоминающие устройства MS-DOS. (Термин "загрузчик" также используется для обозначения той части операционной системы, которая управляет пересылкой прикладных программ в память для выполнения. Такой загрузчик отличается от загрузчика, за- писанного в ПЗУ и загрузчика операционной системы). 1.2. BIOS операционной системы MS-DOS BIOS, загружаемая из файла IO.SYS во время инициализации системы, является уровнем операционной системы, который находится между ядром операционной системы и аппаратными средствами. Прикладные программы осуществляют ввод и вывод путем выдачи требований к ядру операционной системы, которая, в свою очередь, вызывает подпрограммы BIOS операци- онной системы MS-DOS, которые непосредственно осуществляют доступ к аппаратным средствам. См.: ОБРАЩЕНИЯ К ОПЕРАЦИОННОЙ СИСТЕМЕ. Системные вызовы. Такое разделение функций позволяет писать прикладные программы в аппаратно-независимой манере. BIOS операционной системы MS-DOS состоит из некоторой программы инициализации и набора драйверов устройств. (Драйвер устройства - это специализированная программа, которая обеспечивает поддержку специфи- ческого устройства, такого как дисплей или последовательный порт). Драйверы устройств отвечают за доступ к аппаратным средствам и за об- служивание прерываний, что позволяет соответствующим устройствам сиг- нализировать микропроцессору о том, что они нуждаются в обслуживании. Драйверы устройств, содержащиеся в файле IO.SYS, которые всегда загружаются в процессе инициализации системы, иногда называются рези- дентными драйверами. В версии MS-DOS 2.0 (и более поздних) дополни- тельные драйверы устройств, называемые устанавливаемыми, могут (необя- зательно) быть загружены в процессе инициализации системы как резуль- тат директив DEVICE в файле конфигурации системы. См.: ПРОГРАММИРОВАНИЕ В СРЕДЕ MS-DOS: Настройка MS-DOS: Устанавливаемые драйверы устройств; КОМАНДЫ ПОЛЬЗОВАТЕЛЯ: config.sys: device. 1.3. ЯДРО MS-DOS Сервисные возможности, обеспечиваемые ядром MS-DOS для прикладных программ, включают: * Управление процессом * Управление памятью * Поддержка периферийных устройств * Файловая система Ядро MS-DOS загружается из файла MSDOS.SYS во время инициализации сис- темы. 1.3.1. Управление процессом Управление процессом (или задачей) включает: загрузку программы, выполнение задачи, завершение задачи, планирование задачи, междузадач- ную связь. Хотя MS-DOS не является многозадачной операционной системой, он может иметь программы, находящиеся в памяти в одно и тоже время. Одна программа может вызвать другую, которая становится активной (приори- тетной) задачей. Когда вызванная задача завершается, то вызывавшая программа опять становится приоритетной задачей. Так как эти задачи никогда не выполняются одновременно, то эта стэко-подобная операция может рассматриваться сейчас как однозадачная операционная система. MS-DOS имеет несколько искусственных возможностей, которые позволяют некоторым программам реализовывать некоторую многозадачность. Напри- мер, резидентные программы типа "завершиться-и-остаться-резидент- ной"(TSR - terminate-and-state-resident programs), такие как PRINT, используют такие возможности для выполнения ограниченной параллельной обработки, управляя системными ресурсами пока MS-DOS "отдыхает". Окон- ная операционная среда фирмы Microsoft обеспечивает поддержку для пе- реключения невыгружаемой задачи. Традиционные методы междузадачной связи включают семафоры, запро- сы, совместноиспользуемые память и каналы. Из них MS-DOS формально поддерживает только каналы. (Канал - это логический, однонаправленный, последовательный поток данных, который пишется одной программой, а чи- тается другой). Данные в канале располагаются в памяти или на дисковом файле в зависимости от реализации; MS-DOS использует дисковые файлы для промежуточного хранения данных в каналах, потому что MS-DOS - это однозадачная операционная система. 1.3.2. Управление памятью Так как количество памяти, требуемое программе, изменяется от программы к программе, традиционные операционные системы обычно обес- печивают функции управления памятью. Требования на размер памяти мо- гут также меняться в процессе выполнения программыю. Кроме того уп- равление памятью особенно необходимо когда две или более программ на- ходятся в памяти в одно и тоже время. Управление памятью MS-DOS базируется на пуле блоков памяти изме- няющихся размеров. Два основных действия по управлению памятью состо- ят: в выделении блока памяти из пула и в возвращении выделенного бло- ка в пул. MS-DOS во время загрузки программы выделяет ей из пула па- мять; программа, в свою очередь, может получить дополнительную память из пула. Много программ реализуют свое управление памятью, используя локальный пул памяти или динамическую область - дополнительный блок памяти, выделяемый операционной системой, который сама прикладная программа делит на блоки, используемые различными программа- ми.См.:ПРОГРАММИРОВАНИЕ В СРЕДЕ MS-DOS: Программирование для MS-DOS: Управление памятью. 1.3.3. Обслуживание внешних устройств Операционная система обеспечивает программам связь с внешними ус- тройствами посредством набора обращений к операционной системе, кото- рые транслируются операционной системой в вызовы соответствующего драйвера устройства. Поддержка внешних устройств может состоять в прямом переводе ло- гического устройства в физическое или операционная система может вставлять дополнительные свойства или устройства. Клавиатуры, дисп- леи, принтеры обычно требуют только перевода логического устройства в физическое, т.е. данные перемещаются операционной системой между прик- ладной программой и физическим устройством с минимальными измене- ни- ями, если они вообще происходят. С другой стороны, данные, выдавае- мые устройством "таймер", должны быть трансформированы в форматы опе- рационно-зависимых времени и даты. Дисковые устройства (и вообще уст- ройства, обмен с которыми происходит блоками) имеют наибольшее коли- чество свойств, добавляемых операционной системой. См.: Файловая сис- тема. Как утверждалось ранее, потребность прикладной программы в пери- ферии не должна касаться подробностей периферийных устройств или ка- ких-либо специальных свойств, которые имеет периферийное устройство. Так как операционная система заботится о всех преобразованиях логи- ческих устройств в физические, то прикладная программа должна только производить запросы к операционной системе. 1.3.4. Файловая система Файловая система является одной из наибольших частей операционной системы. Файловая система является надстройкой над носителем данных блочного устройства (обычно это дисковод гибких магнитных дисков или винчестер), которая преобразовывает структуру каталога и файлы в фи- зическую единицу памяти. Файловая система на диске содержит, как ми- нимум, информацию о размещении файлов, каталог и объем файлов. См.: ПРОГРАММИРОВАНИЕ В СРЕДЕ MS-DOS: Структура MS-DOS: Запоминающие уст- ройства MS-DOS. Информация о размещении файлов может принимать различные формы в зависимости от операционной системы, но все формы, в основном, отсле- живают пространство, используемое файлами и пространство доступное для новых данных. Каталог содержит список файлов, хранимых на устройстве, их размеры и информацию о размещении этих файлов. Существует несколько различных подходов при размещении файлов и элементов каталога. MS-DOS использует специфический метод размещения, называемый таблицей размещения файлов (FAT), и иерархическую структу- ру каталога. См.: ПРОГРАММИРОВАНИЕ В СРЕДЕ MS-DOS: Структура MS-DOS: Запоминающие устройства MS-DOS; Программирование для MS-DOS: Дисковые каталоги и метки тома. Степень детализации файла, имеющаяся в распоряжении операционной системы, также сильно колеблется в зависимости от реализации. Некото- рые системы, такие как MS-DOS, имеют файлы, которые доступны на уров- не байта; другие системы ограничивают этот доступ фиксированным раз- мером записи. Файловые системы иногда расширяются до таблицы символьных устрой- ств, так как бы они были файлами. Эти "файлы" устройств могут откры- ваться, закрываться, читаться, в них можно записывать информацию как в обычные дисковые файлы, но все транзакции происходят непосредственно с устройством, специфицированным символом. Файлы устройства обеспечивают полезную согласованность среды для прикладных программ. MS-DOS поддер- живает такие файлы путем назначения резервного логического имени (та- кие как CON или PRN) каждому символьному устройству. 1.4. Пользовательский интерфейс Пользовательский интерфейс для операционной системы, также назы- ваемый командным процессором, является, в основном, обычной програм- мой, которая позволяет пользователю взаимодействовать с операционной системой. Используемый в MS-DOS, по умолчанию, пользовательский интер- фейс является заменяемой управляющей программой и называется COMMAND.COM. Одной из основных задач командного процессора является загрузка по требованию программы в память и передача управления от системы программе, с целью выполнения этой программы. Когда выполнение прог- раммы завершается управление передается командному процессору, который предлагает пользователю следующую команду. Кроме того, командный про- цессор обычно включает функции поддержки и вывода на экран каталогов файлов. Теоретически большинство таких функций могут быть реализованы как программы. Однако делая эти функции резидентными в командном про- цессоре, можно значительно ускорить доступ к ним. Результатом такой "сделки" является потеря памяти, но выигрыш в скорости и гибкости. Ранние микрокомпьютерные операционные системы из-за ограниченной памя- ти обеспечивали минимальный набор резидентных команд командного про- цессора; современные операционные системы, такие как MS-DOS, включают широкий набор резидентных команд в качестве внутренних команд. 1.5. Вспомогательные программы Программное обеспечение MS-DOS включает вспомогательные програм- мы, которые обеспечивают доступ к средствам операционной системы и ко- торые не являются резидентными командами командного процессора, встро- енными в COMMAND.COM. Так как такие программы хранятся на диске как исполняемые файлы, то они являются, в сущности, такими же, что и прик- ладные программы и MS-DOS загружает и выполняет их как любую приклад- ную программу. Вспомогательные программы, обеспечиваемые MS-DOS, часто рассмат- риваемые как внешние команды, включают дисковые утилиты, такие как FORMAT и CHKDSK и более общие вспомогательные программы, такие как EDLIN (строко-ориентированный текстовый редактор) и PRINT (TSR-утили- та, позволяющая распечатывать файлы во время выполнения другой прог- раммы). См.: КОМАНДЫ ПОЛЬЗОВАТЕЛЯ. 1.6. Версии операционной системы MS-DOS С 1981 года было выпущено несколько версий MS-DOS и PC-DOS. См.: Развитие MS-DOS. Основные версии MS-DOS и PC-DOS сведены в следующую таблицу: --------------------------------------------------------------------- Версия Год Специальные характеристики --------------------------------------------------------------------- PC-DOS 1.0 1981 Первая операционная система для IBM PC. Файлы - записе-ориентированные. PC-DOS 1.1 1982 Обеспечение работы с двусторонней дис- кетой MS-DOS 1.25 1982 Первая промышленная законченная версия MS-DOS MS-DOS/PC-DOS 2.0 1983 Операционная система для IBM PC/XT. UNIX/XENIX-подобная файловая система. Устанавливаемые драйверы устройств. Байт-ориентированные файлы. Поддержка фиксированных дисков PC-DOS 2.1 1983 Операционная система для более поздних разработок IBM PC MS-DOS 2.11 1983 Интернационализация разработок Исправление ошибок, имевших место в версии 2.0 MS-DOS/PC-DOS 3.0 1984 Операционная система для IBM PC/AT. Поддержка 1.2 Мбайтных флоппи-дисков MS-DOS/PC-DOS 3.1 1984 Поддержка сетей, разработанных в фирме Microsoft MS-DOS/PC-DOS 3.2 1986 Поддержка 3.5 дюймовых флоппи-дисков. Внесение в драйверы устройств возможнос- ти форматирования дисковой дорожки MS-DOS/PC-DOS 3.3 1987 Поддержка PS/2 фирмы IBM. Расширенные возможности для учета национальных осо- бенностей. Повышенная производитель- ность файловой системы. Поддержка дис- ков емкостью 32 Мб по разделам ---------------------------------------------------------------------- PC-DOS 1.0 была первой коммерческой версией MS-DOS. Она была раз- работана только для IBM PC, которые обычно имели 64 Кб памяти или меньше. Версии 1.x MS-DOS и PC-DOS в очень многом были подобны CP/M - популярной операционной системе для 8-разрядных микрокомпьютеров, ос- нованных на микропроцессоре Intel 8080 (предшественник микропроцессора 8086). Эти версии MS-DOS использовали одноуровневую файловую систему без поддержки подкаталогов и не поддерживали устанавливаемые драйверы устройств или сетей. Программы получали доступ к файлам через блоки управления файлами (FCB), подобно тому, как это было сделано в прог- раммах, написанных в среде CP/M. Операции над файлами были записе-ори- ентированными, опять же как в CP/M, хотя в MS-DOS размеры записи уже могли варьироваться. Версии 2.x MS-DOS и PC-DOS, хотя и оставались совместимыми с вер- сиями 1.x, предоставляли большие возможности. В добавление к обеспе- ченной поддержке жестких дисков, новые версии перешли на иерархическую файловую систему, как это было сделано в операционной системе UNIX/XENIX, и к управляемому доступу к файлам вместо блоков FCB. (Уп- равляемый доступ - это 16-разрядный номер, используемый для ссылки к внутренней таблице MS-DOS, которую MS-DOS использует для хранения ад- ресов дорожек уже открытых файлов; прикладные программы не имеют дос- тупа к этой внутренней таблице). Файловые функции в стиле UNIX/XENIX позволяют рассматривать файлы как поток байтов, а не как набор запи- сей. Прикладные программы могут писать или читать от 1 до 65535 байтов за одну операцию, начиная с любого байта файла. Имена файлов, исполь- зуемые при открытии файлов передаются в качестве параметров как текс- товые строки вместо того, чтобы после синтаксического анализа записы- ваться в FCB. Устанавливаемые драйверы устройств также явились одним из основных усилений версий 1.x. Версии 3.x MS-DOS и PC-DOS добавили большое количество существен- ных свойств, включая поддержку дополнительных возможностей IBM PC/AT для более емкостных дисков и для функций захвата файла и захвата запи- си. Путем внедрения способов для переназначения управления (дополни- тельный модуль операционной системы, который имеет возможность пере- назначать локальные системные сервисные запросы к удаленной системе средствами локальной вычислительной сети) была обеспечена поддержка сетевой работы. Со всеми этими изменениями MS-DOS остается традицион- ной однозадачной операционной системой. Она обеспечивает большое коли- чество системных сервисных средств в "прозрачном" виде так, что пока прикладные программы используют только сервисные средства, поставляе- мые MS-DOS, и воздерживаются от использования операций, использующих особенности аппаратного обеспечения, то написанные в MS-DOS для одной машины, они обычно могут выполняться на другой. 1. Основные требования для функционирования MS-DOS Прежде всего, самым необходимым требованием для функционирования MS-DOS является микропроцессор, совместимый с Intel 8086. См.: Специ- альные требования к аппаратному обеспечению. Следующим требованием является наличие начального, расположенного в ПЗУ, загрузчика и объем оперативной памяти достаточный для размеще- ния BIOS, ядра MS-DOS, пользовательского интерфейса и прикладных прог- рамм. Оперативная память должна начинаться с адреса 0000:0000H, должна быть доступна MS-DOS и должна быть непрерывна. Верхний предел для ОП - это предел, устанавливаемый системе семейством микропроцессоров Intel 8086, равный 1 Мб. Последним требованием для MS-DOS является наличие набора устрой- ств (поддерживаемых драйверами устройств), включая по крайней мере од- но блочное устройство, одно символьное устройство и часовое устройст- во. Блочное устройство - это обычно дисковое устройство, с которого загружается MS-DOS; символьное устройство - это обычно комбинация кла- виатура/дисплей для взаимодействия с пользователем; часовое устройст- во, требуемое для поддержки времени дня и даты, это аппаратно-встроен- ный счетчик, изменяющий свое значение через 1 секунду. 1.1. Специальные требования к аппаратному обеспе- чению MS-DOS использует несколько аппаратных компонент и имеет специ- альные требования для каждой из них. Этими компонентами являются: * Микропроцессор семейства Intel 8086 * Память * Внешние устройства * BIOS на ПЗУ (только PC-DOS) 1.1.1. Микропроцессор MS-DOS может функционировать на любой машине, имеющей микропро- цессор, реализующий набор команд микропроцессора 8086/8088, включая Intel 8086, 80C86, 8088, 80186, 80V88, 80286, 80386 и NEC V20, V30 и V40. Микропроцессоры 80186 и 80188, которые являются версиями микроп- роцессоров 8086 и 8088, расположены на одной микросхеме с обеспечением прямого метода доступа, таймера и функциями, реализующими прерывания. Обычно PC-DOS не может функционировать на микропроцессорах 80186 или 80188, потому что эти микропроцессоры имеют адреса внутреннего преры- вания и интерфейсного регистра, которые не согласуются с адресами, ис- пользуемыми BIOS на ПЗУ системы PC-DOS. См.: ПРОГРАММИРОВАНИЕ В СРЕДЕ MS-DOS: Настройка MS-DOS: Аппаратные обработчики прерываний. Однако, MS-DOS не имеет адресных требований, которые конфликтуют с областями прерывания и интерфейса. Микропроцессор 80286 имеет расширенный набор команд и два режима работы: режим реальной адресации и защищенный режим. Режим реальной адресации (real mode) совместим с микропроцессорами 8086/8088 и допус- кает функционирование MS-DOS. Защищенный режим (protected mode), ис- пользуемый такими операционными системами, как UNIX/XENIX и MS OS/2, является частично совместимым с режимом реальной адресации с точки зрения команд, но обеспечивает доступ к 16 Мб памяти против 1 Мб в ре- жиме реальной адресации (предел микропроцессоров 8086/8088). Микропроцессор 80386 добавляет новые команды и третий режим, на- зываемый виртуальным 86 режимом. Команды микропроцессора 80386 функци- онируют либо в 16-битной либо в 32-битной среде. MS-DOS может функцио- нировать на микропроцессоре 80386 в режиме реальной адресации или вир- туальном 86 режиме, хотя последний требует дополнительную поддержку в форме монитора виртуальной машины, такого как Windows/386. 1.1.2. Требования к памяти Версии 1.x MS-DOS требуют, как минимум, 64 К непрерывной памяти. Версии 2.x и 3.x требуют по меньшей мере 128 Кб. Максимумом является 1 Мб, хотя большинство MS-DOS машин имеют предел 640 Кб для совместимос- ти с IBM PC. MS-DOS может использовать дополнительную ненепрерывную ОП для RAM-диска (RAM-диск - псевдодиск - это логическое устройство, обеспечивающее хранение файлов в специально выделенной области ОП), если включен драйвер соответствующего устройства. (Другие применения ненепрерывной ОП - это буферы для видеодисплеев, фиксированных дисков и адаптеров сетей). Для PC-DOS существуют те же минимальные требования для ОП, но эта операционная система имеет верхний предел в 640 Кб для начальной неп- рерывной ОП, который вообще рассматривается как наибольшая память. Этот предел был обусловлен архитектурой первоначальной IBM PC: остав- шаяся (свыше 640Кб) область резервируется для буферов видеодисплея, адаптеров жестких дисков и BIOS на ПЗУ. Некоторые из резервируемых об- ластей включают: --------------------------------------------------------------------- Базовый адрес Размер(в байтах) Описание --------------------------------------------------------------------- A000:0000H 10000H (64 Кб) Буфер видео EGA B000:0000H 1000H ( 4 Кб) Буфер для монохромного видео- дисплея B800:0000H 4000H (16 Кб) Буфер для цветного/графичес- кого видео-дисплея C800:0000H 4000H (16 Кб) ПЗУ фиксированного диска F000:0000H 10000H (64 Кб) PC ROM BIOS и ROM BASIC -------------------------------------------------------------------- Начальные 1024 байта системной оперативной памяти (позиции 00000 - 003FFH) используются микропроцессором для таблицы векторов прерыва- ний - т.е. списков адресов для программ обработки прерываний. MS-DOS использует некоторые из входов в этой таблице, такие, как вектора для прерываний от 20H до 2FH, для хранения адресов своих собственных таб- лиц и программ и для обеспечения связи прикладных программ со своими сервисными программами. IBM PC ROM BIOS и IBM PC BASIC для тех же це- лей используют много дополнительных векторов. 1.1.3. Внешние устройства MS-DOS может поддерживать много разных устройств, включая флоп- пи-диски, фиксированные диски, оптические диски, RAM-диски и цифровые ленточные устройства. Необходимая поддержка внешних устройств в MS-DOS обеспечивается BIOS или устанавливаемыми драйверами устройств. Основная конфигурация MS-DOS обеспечивает пять логических устрой- ств: ------------------------------------------------------------- Имя устройства Описание ------------------------------------------------------------- CON Ввод и вывод с консоли PRN Вывод на печатающее устройство AUX Вспомогательный ввод и вывод CLOCK$ Поддержка даты и времени A - E Одно блочное устройство ------------------------------------------------------------- Эти пять логических устройств могут быть реализованы, если BIOS поддерживает как минимум три физических устройства: клавиатура и дис- плей, микросхема таймера или часы/календарь, которая может обеспечи- вать аппаратные прерывания через регулярные интервалы, и дисковое за- поминающее устройство. При такой минимальной конфигурации принтер и вспомогательное устройство являются просто дополнительными именами для консольного устройства. Однако, большинство машин, использующих MS-DOS, поддерживают несколько дополнительных логических и физических устройств. См.: ПРОГРАММИРОВАНИЕ В СРЕДЕ MS-DOS: Символьное устройст- во ввода и вывода. Ядро MS-DOS обеспечивает одно дополнительное устройство - NUL. NUL - это "черная дыра", т.е., что бы ни записывалось в NUL - просто пропадает. Чтение из NUL всегда возвращает маркер конца файла. Обычным применением для устройства NUL является переназначение выводного уст- ройства в команде или прикладной программе, запускаемой в командном файле; это переназначение предохраняет экран от хлама, не приводит к разрушению меню командных файлов и изображений, выведенных на дисплей. 1.1.4. BIOS на постоянных запоминающих устройствах MS-DOS не требует для себя никакой поддержки от ПЗУ (исключая только то, что большинство первоначальных загрузчиков расположены в ПЗУ) и не отслеживает расположены ли драйверы устройств в ПЗУ или яв- ляются частью файла IO.SYS, загружаемого в момент инициализации. С другой стороны, PC-DOS использует очень специфический BIOS на ПЗУ. PC BIOS на ПЗУ не поддерживает драйверы устройств, скорее он поддержива- ет вспомогательные программы, используемые драйверами устройств, на- ходящимися в IBMBIO.COM (версия IO.SYS в PC-DOS). Поддержка, обеспечиваемая PC BIOS включает: * Тест самопроверки при включении (Power-on Self Test)(POST) * Начальный загрузчик * Клавиатура * Дисплеи (монохромные и цветные/графические адаптеры) * Последовательные порты 1,2 и 3 * Часы * Печать содержимого экрана Программа загрузки в BIOS для операционной системы PC-DOS ищет место для дополнительных ПЗУ за пределами максимальной памяти (640 Кб). Адаптер фиксированного диска фирмы IBM и расширенный графический адаптер (EGA) содержат такие ПЗУ. (ПЗУ для фиксированного диска вклю- чает дополнительную программу загрузчика, которая позволяет загру- зиться с фиксированного диска). 2. Заключение MS-DOS - это получившая широкое признание традиционная операцион- ная система. Ее компоненты и хорошо определенный интерфейс делают ее одной из наиболее легких операционных систем для применения и програм- мирования. MS-DOS - это также развивающаяся операционная система: в каждой версии добавляется много новых характеристик и возможностей, что дела- ет систему более легкой для использования конечными пользователями и программистами. Кроме того, каждая версия включает дополнительные воз- можности для поддержки различных устройств: от 5,25 дюймовых гибких дисков до 3,5 дюймовых с высокой плотностью записи. По мере развития аппаратуры и усложнения пользовательских потребностей MS-DOS будет также продолжать развиваться. Вильям Ванг Глава 2. Компоненты MS-DOS MS-DOS является модульной операционной системой, состоящей из многих компонент со специфичными функциями. В процессе загрузки MS-DOS в память многие из ее компонент копируются, настраиваются в связи с особенностями среды или уничтожаются по окончании их работы. Однако, в процессе выполнения MS-DOS является относительно статической , поведе- ние ее компонент предсказуемо, и их легко изучать. Поэтому в этой гла- ве рассматривается сначала особенности выполнения MS-DOS , а затем особенности ее поведения во время загрузки. 1. Основные элементы MS-DOS состоит из трех основных модулей: ---------------------------------------------------------------------- Модуль Имя файла в MS-DOS Имя файла в PC-DOS ---------------------------------------------------------------------- MS-DOS BIOS IO.SYS IBMBIO.COM Ядро MS-DOS MSDOS.SYS IBMDOS.COM Командный процессор MS-DOS COMMAND.COM COMMAND.COM ---------------------------------------------------------------------- Во время процесса инициализации системы эти модули загружаются в память в указанном порядке сразу за таблицей векторов прерываний, рас- положенной в младших адресах памяти. Все три модуля остаются в памяти до тех пор, пока не будет выполнена перезагрузка либо выключение ком- пьютера. (Загрузчик и модули инициализации системы исключаются из этого списка, так как занимаемая ими память освобождается сразу же после начала функционирования MS-DOS. См.: Загрузка MS-DOS). Обычно BIOS MS-DOS поставляется для конкретного компьютера изго- товителем оборудования, который распространяет MS-DOS . (См.: ПРОГРАМ- МИРОВАНИЕ В СРЕДЕ MS-DOS: Структура MS-DOS: Введение в MS-DOS.) Ядро MS-DOS поставляется фирмой Microsoft и является одинаковым у всех из- готовителей оборудования для конкретной версии MS-DOS, которые не про- изводят никаких модификаций ядра. Командный процессор является замеща- емым модулем, который поставляется изготовителем оборудования или мо- жет быть заменен пользователем. По умолчанию это COMMAND.COM, постав- ляемый фирмой Microsoft. 1.1. BIOS MS-DOS Файл IO.SYS содержит BIOS MS-DOS и модуль инициализации MS-DOS - SYSINIT. BIOS MS-DOS настраивается на конкретную машину изготовителем оборудования. SYSINIT поставляется фирмой Microsoft и помещается изго- товителем оборудования в файл IO.SYS в момент создания этого файла. (См.: Загрузка MS-DOS.) BIOS MS-DOS состоит из списка резидентных драйверов устройств и дополнительного модуля инициализации, создавае- мого фирмой-изготовителем оборудования. Драйверы устройств располага- ются в IO.SYS, потому что после инициализации IO.SYS они остаются ре- зидентными; программа же инициализации BIOS MS-DOS и SYSINIT после инициализации обычно освобождают занимаемую ими память. Минимальный набор резидентных драйверов устройств - это CON, PRN, AUX, CLOCK$ и драйвер для одного блочного устройства. Резидентные драйверы символьных устройств появляются в списке драйверов перед драйверами блочных устройств; устанавливаемые (инсталлируемые) драйве- ры символьных устройств располагаются в списке впереди резидентных драйверов устройств; загружаемые драйверы блочных устройств располага- ются в списке после резидентных драйверов устройств. Эта последова- тельность позволяет устанавливаемым драйверам символьных устройств за- менять резидентные драйверы. Драйвер устройства NUL, который должен быть первым драйвером в цепочке, содержится в ядре MS-DOS. Программный код драйвера устройства может быть распределен между IO.SYS и ПЗУ. Например, большинство систем MS-DOS и все системы, сов- местимые с PC-DOS, имеют расположенный в ПЗУ BIOS, который содержит простые программы обслуживания устройств. Эти программы в основном ис- пользуются резидентными и загружаемыми драйверами для расширения прог- рамм, находящихся в ОП. (Размещение драйвера в ОП целиком делает драй- вер зависимым от особенностей аппаратной конфигурации, размещение час- ти драйвера в ПЗУ позволяет соединить BIOS MS-DOS с особым интерфей- сом, размещенным в ПЗУ, который остается постоянным для многих различ- ных аппаратных конфигураций). Файл IO.SYS представляет собой программу в абсолютных адресах, и она не содержит информацию для настройки программы. Программы в IO.SYS написаны в предположении, что регистр CS содержит сегмент памяти, куда происходит загрузка файла. Таким образом, IO.SYS имеет то же ограниче- ние в 64 Кбайт, что и .COM файл. (См.: ПРОГРАММИРОВАНИЕ В СРЕДЕ MS-DOS: Программирование для MS-DOS: Структура прикладных программ.) Допустимы файлы IO.SYS большего размера , но заголовки драйверов уст- ройств должны располагаться в пределах первых 64 Кбайт, а программа должна включать на свой собственный арифметический блок вычисления ад- ресов для получения доступа к программам, выходящим за пределы первых 64 Кбайт. 1.2. Ядро MS-DOS Ядро MS-DOS - это сердце MS-DOS, которое обеспечивает функциони- рование всех функций, характерных для традиционных операционных сис- тем. Ядро содержится в единственном файле - MSDOS.SYS, поставляемом корпорацией Microsoft. Функции, предоставляемые ядром прикладным прог- раммам, - называемые системными функциями - апаратно независимы. Это достигается путем использования драйверов устройств льским программам, являются аппаратно-независимыми и, следовательно, не зависят от харак- теристик оборудования, так как операции по выполнению физического вво- да и вывода воз(включаемых в состав MS-DOS BIOS) для осуществления операций обмена данными (ввода/вывода) на физическом уровне. Ядро MS-DOS предоставляет следующие возможности (реализуемые с помощью драйверов устройств): * Управление файлами и каталогами. * Поддержка ввода и вывода для символьных устройств. * Поддержка времени и даты. Ядро обеспечивает также функции, не имеющие отношения к устройст- вам: * Управление памятью. * Управление задачей и средой. * Установление конфигурации, учитывающей особенности конкретной страны. Системные функции доступа к программам используют команды прог- раммных прерываний (INT). Для этих целей MS-DOS резервирует прерывания от 20H до 3FH. Это следующие прерывания: Прерывание 21H - это основное средство обращения к возможностям MS-DOS. Функции прерывания 21H реализуются путем установки номера фун- кции в регистр AH, размещения необходимых параметров в другие регистры и выдачи команды INT 21H. (MS-DOS также поддерживает call-интерфейс ---------------------------------------------------------------------- Прерывание Название ---------------------------------------------------------------------- 20H Завершить программу 21H Обращение к функциям MS-DOS 22H Адрес программы обработки завершения задачи 23H Адрес программы реакции на Control-C 24H Адрес программы реакции на фатальную ошибку 25H Чтение с диска по абсолютному адресу 26H Запись на диск по абсолютному адресу 27H Завершить программу и оставить ее резидентной 28H - 2EH Резервируются 2FH Мультиплексность 30H - 3FH Резервируются ---------------------------------------------------------------------- для совместимости с CP/M. Содержимое регистров функции и параметров в этом случае отличаются от соответствующих в интерфейсе прерываний. Ин- терфейс CP/M был разработан для версии 1.0 исключительно для обеспече- ния переноса разработок, основанных на CP/M, в MS-DOS. Современные разработки используют исключительно функции, обеспечиваемые прерывани- ем 21H). В версии 2.0 введен механизм модификации функционирования MS-DOS BIOS и ядра MS-DOS: файл CONFIG.SYS. Это текстовой файл, содержащий командные опции, которые модифицируют размер или конфигурацию внутрен- них таблиц MS-DOS и позволяют загрузить дополнительные драйверы уст- ройств. Этот файл читается, когда MS-DOS впервые загружается в память. (См.: КОМАНДЫ ПОЛЬЗОВАТЕЛЯ: CONFIG.SYS.) 1.3. Командный процессор MS-DOS Командный процессор, или командный интерпретатор, является первой у "командный интерпретатор" программой, запускаемой MS-DOS после заг- рузки и инициализации MS-DOS BIOS и ядра. Он обеспечивает интерфейс между ядром и пользователем. Стандартный командный процессор MS-DOS - COMMAND.COM - это команд- но-ориентированный интерфейс; другие коман- дные процессоры могут быть ориентированы на использование меню и эк- рана. COMMAND.COM - это замещаемый командный процессор. Многие коммер- ческие продукты могут использоваться в качестве COMMAND.COM, кроме то- го, программист может разработать свой командный процессор. Новый ко- мандный процессор устанавливается либо переименованием его в COMMAND.COM, либо при помощи команды SHELL в файле CONFIG.SYS. Послед- ний метод предпочтительней, так как он допускает передачу коман- дному процессору параметров его инициализации. COMMAND.COM может выполнять множество внутренних (встроенных) ко- манд, загрузку и выполнение программ или интерпретировать командные файлы. Большинство из внутренних команд поддерживают работу с файлами и каталогами и манипулируют сегментом используемой среды программы, обслуживаемой COMMAND.COM. Программами, выполняемыми COMMAND.COM, яв- ляются файлы .COM или .EXE, загружаемые с блочного устройства. Для на- писания командных файлов .BAT, поддерживаемых COMMAND.COM, обеспечива- ется ограниченный язык программирования. Эти файлы являются полезными для выполнения небольших, часто используемых серий команд MS-DOS. В частности, COMMAND.COM, когда он впервые загружается системой, ищет сначала файл командных файлов AUTOEXEC.BAT, интерпретирует его (если он есть), а затем уже выполняет другие действия. COMMAND.COM также обеспечивает стандартное завершение задачи, реакцию на Control-C и фа- тальную ошибку. Адреса подпрограмм, обрабатывающих эти ситуации, хра- нятся в векторах прерываний 22H, 23H, 24H. (См.: ПРОГРАММИРОВАНИЕ В СРЕДЕ MS-DOS: Настройка MS-DOS: Программы обработки особых ситуаций.) 1.3.1. Разделение обязанностей в COMMAND.COM COMMAND.COM - это обычная .COM-программа, с небольшими особеннос- тями. Обычно .COM-программа загружается в один сегмент памяти. Начиная выполняться, COMMAND.COM копирует свою нерезидентную часть в старшие адреса памяти , сохраняя резидентную часть в младших адресах. Память, идущая за резидентной частью, освобождается для MS-DOS. Результат такого разделения никак не проявляется до тех пор, пока не завершится выполнение программы и управление не будет передано ре- зидентной части COMMAND.COM. Резидентная часть вычисляет контрольную сумму области старших адресов памяти , где должна находиться нерези- дентная часть COMMAND.COM, чтобы определить, не является ли она затер- той. Если контрольная сумма равна заданому значению, то нерезидентная часть считается нетронутой. В противном случае копия нерезидентной части снова загружается с диска, и COMMAND.COM продолжает свои обычные действия. Такое "разделение обязанностей" существует потому, что MS-DOS с самого начала разрабатывалась для систем с ограниченным объемом опера- тивной памяти. Нерезидентная часть COMMAND.COM, содержащая программы выполнения командных файлов и встроенные команды , которые не являются необходимыми в случае получения управления и необходимости новой заг- рузки, обычно значительно больше резидентной части, необходимой для выполнения таких действий. Таким образом, возможность затирания нере- зидентной части позволяет освободить дополнительную оперативную память и запускать более объемные прикладные программы. 1.3.2. Выполнение команд Выполнение команд в COMMAND.COM начинается со сравнения имени специфицированной команды с именами внутренних команд. Если сравнение прошло успешно, то команда выполняется. Иначе COMMAND.COM ищет файл среди файлов .COM, .EXE, .BAT (в таком порядке) с заданным именем. Ес- ли найдена программа .COM или .EXE, то COMMAND.COM использует функцию MS-DOS EXEC (прерывание 21H функция 4BH) для загрузки программы и ее выполнения; .BAT-файлы COMMAND.COM интерпретирует сам. Если не найдено ни одного файла, то выдается сообщение "Неправильная команда или имя файла" (Bad command or file name). Хотя обычно команда - это просто имя файла без расширения, в вер- сии MS-DOS 3.0 и более поздних допускается перед именем команды указы- вать полный путь доступа к файлу. Если путь не определен полностью, то поисковый механизм COMMAND.COM использует содержание переменной коман- ды PATH, которая может содержать список путей доступа, используемый командами. Поиск начинается с текущего каталога , проходит через ката- логи, определенные в PATH, и осуществляется до тех пор, пока файл не будет найден, либо список не будет исчерпан. Например, спецификация PATH: PATH C:\BIN;D:\BIN;E:\ указывает COMMAND.COM начать поиск сначала в текущем каталоге, затем в C:\BIN, D:\BIN и окончательно в корневом каталоге устройства E. COMMAND.COM просматривает каталоги для поиска .COM, .EXE или .BAT фай- ла именно в том порядке, который указан. 1.3.3. Среда MS-DOS В версии 2.0 вводится концепция среды MS-DOS. Среда - это вырав- ненный на параграф сегмент памяти, содержащий сконкатенированное мно- жество строк переменной длины, заканчивающихся нулем (ASCIIZ), в фор- ме: variable=value, которая обеспечивает такую информацию, как текущий путь поиска, ис- пользуемую COMMAND.COM для нахождения исполняемых файлов, расположение самого COMMAND.COM и формат пользовательской подсказки. Конец множест- ва строк отмечается нулевой строкой, т.е. одним нулевым байтом. Специ- фическая среда связывается с каждой программой в памяти посредством указателя, содержащегося со смещением 2CH в 256-байтном программном префиксном сегменте (program segment prefix - PSP). Максимальный раз- мер среды - 32 Кб, по умолчанию 160 байт. Если программа использует функцию EXEC для загрузки и выполнения другой программы, то содержимое новой программной среды становится доступным MS-DOS с помощью инициирующей программы - один из параметров функции EXEC является указателем на среду новой программы. По умолча- нию среда, образующаяся у новой программы, является копией программной среды инициирующей программы. Сама программа, использующая функцию EXEC для загрузки и выполне- ния, не будет иметь доступа к новой программной среде, потому что MS-DOS обеспечивает указатель к этой среде только новой программе. Лю- бые изменения, произошедшие в новой программной среде в процессе вы- полнения программы, являются невидимыми для инициирующей программы, потому что программная среда программы-потомка всегда исчезает по ее завершении. Системная основная среда обычно ассоциируется с командным процес- сором COMMAND.COM. COMMAND.COM внутри самого себя создает это множест- во строк (сред), используя содержимое файлов CONFIG.SYS и AUTOEXEC.BAT, используя команды SET, PATH и PROMPT. (См. КОМАНДЫ ПОЛЬ- ЗОВАТЕЛЯ: AUTOEXEC.BAT; CONFIG.SYS.) В MS-DOS версии 3.2 начальный размер среды COMMAND.COM может быть управляем при загрузке COMMAND.COM с параметром /E, используя директиву SHELL в CONFIG.SYS. Например, строка SHELL=COMMAND.COM /E:2048 /P помещенная в CONFIG.SYS, устанавливает начальный размер среды COMMAND.COM в 2Кбайта. Опция /P предохраняет COMMAND.COM от заверше- ния, заставляя его, таким образом, оставаться в памяти до перезагрузки или выключения компьютера. Команда SET используется для вывода на экран или изменения содер- жимого среды COMMAND.COM. Команда SET без параметров выводит на экран список всех строк в среде COMMAND.COM. Типичный листинг может выгля- деть следующим образом: COMSPEC=A:\COMMAND.COM PATH=C:\;A:\;B:\ PROMPT=$p $d $t$_$n$g TMP=C:\TEMP Ниже приводится дамп сегмента среды, описанной в приведенном при- мере: 0 1 2 3 4 5 6 7 8 9 A B C D E F 0000 43 4F 4D 53 50 45 43 3D-41 3A 5C 43 4F 4D 4D 41 COMSPEC=A:\COMMA 0010 4E 44 2E 43 4F 4D 00 50-41 54 48 3D 43 3A 5C 3B ND.COM.PATH=C:\; 0020 41 3A 5C 3B 42 3A 5C 00-50 52 4F 4D 50 54 3D 24 A:\;B:\.PROMPT=$ 0030 70 20 20 24 64 20 20 24-74 24 5F 24 6E 24 67 00 p $d $t$_$n$g. 0040 54 4D 50 3D 43 3A 5C 54-45 4D 50 00 00 00 00 00 TMP=C:\TEMP..... Команда SET, которая специфицирует переменную, но не указывает для нее значение, удаляет переменную из среды. Программа может игнорировать содержимое своей среды, однако, ис- пользование среды может сильно увеличить гибкость и возможности пара- метризации командных (batch) файлов и прикладных программ. 1.3.4. Командные файлы Командные файлы - это текстовые файлы с расширением .BAT, которые содержат команды MS-DOS и управляющие команды. Каждая строка в файле ограничена 128 байтами. (См. КОМАНДЫ ПОЛЬЗОВАТЕЛЯ: BATCH.) Командные файлы могут быть созданы при помощи большинства текстовых редакторов, включая EDLIN, а короткие командные файлы могут даже быть созданы при помощи команды COPY: C>COPY CON SAMPLE.BAT Устройство CON является системной консолью; текст, введенный с клавиатуры, появляется на экране по мере печатания. Операция копирова- ния с клавиатуры заканчивается при одновременном нажатии клавиш Ctrl и z (или функциональной клавиши F6 на IBM-совместимых машинах) и после- дующего нажатия клавиши Enter. Командные файлы интерпретируются COMMAND.COM по одной строке за один раз. Кроме стандартных команд MS-DOS, интерпретатор командных файлов командного процессора COMMAND.COM поддерживает набор специаль- ных управляющих команд: ______________________________________________________________________ Команда Значение ______________________________________________________________________ ECHO* Вывод сообщения на экран FOR* Выполнить команду для списка файлов GOTO* Передача управления в другую точку IF* Условное выполнение команды PAUSE Ожидание нажатия любой клавиши REM Вставка комментария SHIFT* Допускается более 10 параметров ______________________________________________________________________ * версии MS-DOS 2.0 и более поздние Выполнение командного файла может быть остановлено нажатием Ctrl-C или Ctrl-Break, в результате чего COMMAND.COM выдает подсказку: Terminate batch job? (Y/N) 1.3.5. Переадресация ввода/вывода Средства переадресации ввода/вывода присутствуют в MS-DOS, начи- ная с версии 2.0. Средства переадресации реализованы в COMMAND.COM при помощи системных функций прерывания 21H: дублирование дескриптора фай- ла (45H) и переадресация дескриптора файла (46H). COMMAND.COM исполь- зует эти функции для обеспечения переадресации как на командном уров- не, так и на уровне программного канала (подобно тому, как это реали- зуется в UNIX/XENIX). Переадресация является невидимой для прикладных программ, но для получения преимуществ от переадресации прикладная программа должна ис- пользовать стандартные входные и выходные идентификаторы дескрипторов файлов (handles). Ввод и вывод в прикладных программах, которые непос- редственно используют экран или клавиатуру или используют функции BIOS, реализованные в ПЗУ, не могут быть переадресованы. Переадресация определяется в командной строке установлением перед именами файла или устройства специальных символов >, >> и < . Стандар- тный вывод (по умолчанию = CON) переадресовывается при помощи символов > и >>, за которыми следует либо имя файла, либо символьное устройст- во. Первый из указанных символов создает новый файл (или перекрывает существующий файл с тем же именем); другой - добавляет текст в конец к существующему файлу (или создает файл, если тот не существует). Стан- дартный ввод (по умолчанию = CON) переадресовывается при помощи симво- ла < , за которым следует имя файла или символьное устройство.( См. ПРОГРАММИРОВАНИЕ В СРЕДЕ MS-DOS: Настройка MS-DOS: Написание фильтров в MS-DOS.) Средство переадресации может быть также использовано при передаче информации от одной программы к другой через "канал". Канал в MS-DOS - это специальный файл, создаваемый COMMAND.COM. COMMAND.COM переадресо- вывает вывод какой-либо программы в этот файл и затем переназначает этот файл как входной для следующей программы. Символ канала, верти- кальная черта (|), разделяет имена программ. В одной командной строке при помощи канала может быть связано вместе несколько имен программ: C>DIR *.* | SORT | MORE Эта команда эквивалентна последовательности: C>DIR *.* | PIPE0 | C>SORT < PIPE0 > PIPE1 C>MORE < PIPE1 Концепция каналов возникла в UNIX/XENIX, но UNIX/XENIX - это мно- гозадачная операционная система, которая фактически выполняет програм- мы одновременно. Для связи программ UNIX/XENIX использует буферы в оперативной памяти, в то время как MS-DOS за один раз запускает одну программу, а информацию передает через дисковые файлы. 2. Загрузка MS-DOS Выход MS-DOS к стандартной подсказке A> - это сложный процесс, имеющий несколько разновидностей. В этом разделе рассматривается пол- ный процесс загрузки, связанный с версиями MS-DOS 2.0 и более поздни- ми. (Версии MS-DOS 1.x используют те же основные этапы загрузки, но в этих версиях не поддерживаются различные системные таблицы и устанав- ливаемые драйверы устройств). Загрузка MS-DOS происходит либо в результате "холодной загрузки", либо "теплой загрузки". На IBM-совместимых машинах холодная загрузка происходит при первом включении компьютера или при аппаратном сбросе. Обычно при холодной загрузке осуществляет выполнение теста самопровер- ки ( power-on self test - POST) и определяется количество доступной памяти и установленные адаптеры периферийных устройств. Тест POST обычно выполняется только при холодной загрузке, так как он требует заметного количества времени. Например, IBM-совместимый ROM BIOS тес- тирует всю обычную и расширенную оперативную память (ОП более 1 Мбайт на машинах с 80286 или 80386 процессорами), что может занять по време- ни десятки секунд. Теплая загрузка, вызываемая одновременным нажатием клавиш Ctrl, Alt и Del, пропускает эти аппаратные проверки и начинает загрузку с контроля диска первоначальной загрузки. Диск первоначальной загрузки обычно содержит маленькую програм- му-загрузчик, которая загружает MS-DOS с того же диска.(См. ПРОГРАММИ- РОВАНИЕ В СРЕДЕ MS-DOS: Структура MS-DOS: Запоминающие устройства MS-DOS.) Тело MS-DOS содержится в двух файлах: IO.SYS и MSDOS.SYS (IBMBIO.COM и IBMDOS.COM для PC-DOS). IO.SYS содержит модуль системной инициализации фирмы Microsoft - SYSINIT, который определяет конфигура- цию MS-DOS, используя либо значения по умолчанию,либо спецификации в файле CONFIG.SYS (если он существует), и затем начинает выполнять уп- равляющую программу (как правило (и по умолчанию) - это COMMAND.COM). COMMAND.COM проверяет файл AUTOEXEC.BAT и, если находит, интерпретиру- ет его. (Другие командные процессоры не обязательно поддерживают такие командные файлы). И, наконец, COMMAND.COM приглашает пользователя ко вводу команды. (Стандартное приглашение MS-DOS - это A>, если система была загружена с флоппи-диска, и C>, если система была загружена с жесткого диска). Каждый из упомянутых этапов загрузки будет детально обсужден ниже. 2.1. BIOS ПЗУ, тест самопроверки POST и первона- чальная загрузка Все микропроцессоры, совместимые с микропроцессорами 8086/8088 начинают работу с установки CS:IP адреса FFFF:0000H, который обычно содержит команду перехода к тому месту в BIOS , которое содержит прог- рамму инициализации для машины. (Это не имеет никакого отношения к MS-DOS; это свойство микропроцессоров фирмы Intel). На IBM-совместимых машинах BIOS ПЗУ занимает адресное пространство с F000:0000H до этой команды перехода. На Рис. 2-1 показано размещение BIOS в 1-Мбайтном адресном пространстве. Дополнительные программы поддержки ПЗУ могут быть расположены перед BIOS (в более младших адресах). Когда микропроцессор начинает работу, прерывания не действуют, и он включает программу инициализации для установки векторов прерываний. -------------------¬ <---- FFFF:000FH (1 Мбайт) ¦ ¦ <---- FFFF:0000H ¦ BIOS ПЗУ ¦ ¦__________________¦ <---- F000:0000H ¦ ¦ ¦ Другие ПЗУ и ¦ ¦ оперативная ¦ ¦ память ¦ ¦__________________¦ <---- Вершина оперативной памяти ¦ ¦ (A000:0000H для IBM PC) ¦ Свободная ¦ ¦ оперативная ¦ ¦ память ¦ L------------------- <---- 0000:0000H Рис. 2-1. Распределение памяти в начальный момент Программа инициализации в BIOS - процедура POST - определяет, ка- кие устройства установлены и включены, проверяет обычную память (пер- вый 1 Мбайт) и, для основанных на 80286-м или 80386-м микропроцессорах машин, расширенную память (свыше 1 Мбайт). Там, где это возможно, уст- ройства тестируются, и любые возникающие проблемы сопровождаются зву- ковыми сигналами , а также выводом сообщений на экран. Если устанавливается, что ЭВМ находится в рабочем состоянии, то BIOS переводит ее в состояние для нормальной работы. Во-первых, иници- ализируются таблица векторов прерываний в начале памяти и любой конт- роллер прерываний, который ссылается на эту таблицу. Область таблицы векторов прерываний расположена в памяти от адреса 0000:0000H до адре- са 0000:03FFH. На IBM-совместимых машинах часть последующей памяти (начиная от адреса 0000:0400H) используется для хранения таблиц, ис- пользуемых различными программами BIOS (Рис. 2-2). Начальный адрес загрузки для системных файлов MS-DOS располагается обычно в пределах адресов от 0000:0600H до 0000:0800H. Далее BIOS устанавливает необходимые аппаратные интерфейсы, та- кие, как контроллеры прямого доступа к памяти (direct memory access - DMA), последовательные порты и т.п. Некоторые аппаратные установки мо- гут быть выполнены перед установкой области таблицы векторов прерыва- ний. Например, контроллер IBM PC DMA также обеспечивает регенерацию для динамических интегральных схем оперативной памяти, и оперативная память не может быть задействована до тех пор, пока не выполнится ре- генерация памяти, осуществляемая DMA. Следовательно, DMA должен уста- навливаться первым. Некоторые реализации BIOS осуществляют проверку установки допол- нительных BIOS , просматривая память от A000:0000H до F000:0000H в по- исках определенной последовательности заполненных байтов. Если обнару- живаются дополнительные BIOS (найдена соответствующая последователь- ность байтов), то вызываются их программы инициализации для инициали- зации соответствующих устройств. Примерами дополнительных ПЗУ для се- мейства IBM PC являются ПЗУ BIOS для фиксированных дисков PC/XT и ПЗУ BIOS для EGA. Затем BIOS начинает процедуру начальной загрузки, выполняя прог- рамму-загрузчик на ПЗУ. На IBM PC эта программа сначала проверяет пер- вое устройство гибких магнитных дисков, тестируя наличие на нем диска первоначальной загрузки. Если там его нет, то программа включает в ра- боту ПЗУ, связанное с другим устройством, которое может содержать диск первоначальной загрузки. Эта процедура повторяется до тех пор, пока диск первоначальной загрузки не будет найден, или до тех пор, по- ка все устройства, которые могут содержать диск первоначальной загруз- ки, не будут проверены. Если поиск безуспешен, вызывается BASIC, запи- санный в ПЗУ. -------------------¬ <---- FFFF:000FH (1 Мбайт) ¦ ¦ <---- FFFF:0000H ¦ BIOS ¦ ¦__________________¦ <---- F000:0000H ¦ ¦ ¦ Другие ПЗУ и ¦ ¦ оперативная ¦ ¦ память ¦ ¦__________________¦ <---- Вершина оперативной памяти ¦ ¦ (A000:0000H для IBM PC) ¦ Свободная ¦ ¦ оперативная ¦ ¦ память ¦ +------------------+ <---- 0000:0600H ¦ ¦ ¦ Таблицы BIOS ¦ ¦ ¦ +------------------+ <---- 0000:0400H ¦ ¦ ¦ Вектора ¦ ¦ прерываний ¦ ¦ ¦ L------------------- <---- 0000:0000H Рис. 2-2. Расположение таблицы векторов прерываний и таблиц BIOS Устройства, с которых может происходить загрузка, могут быть об- наружены множеством способов. BIOS IBM PC читает первый сектор на дис- ке в оперативную память (Рис. 2-3) и проверяет наличие в начале этого сектора короткой либо длинной команды перехода семейства микропроцес- соров 8086 и наличие в последнем слове сектора значения AA55H. Это оз- начает, что сектор содержит загрузчик операционной системы. Если это обычные диски с данными (т.е. диски, на которых не устанавливаются системные файлы MS-DOS), то обычно программа-загрузчик на ПЗУ выдает сообщение, что диск не является системным диском первоначальной заг- рузки. Стандартная процедура выдает сообщение с требованием установить другой диск (с файлами операционной системы) и, нажав требуемую клави- шу, повторить операцию загрузки. Программа-загрузчик на ПЗУ выполняет- ся снова с самого начала, повторяя свою обычную поисковую процедуру. Когда программа-загрузчик на ПЗУ находит устройство, с которого может идти загрузка, она запускает загрузчик операционной системы и передает ему управление. Затем загрузчик операционной системы через таблицу прерываний использует сервисные возможности BIOS ПЗУ для заг- рузки следующей части операционной системы в младшие адреса памяти. Перед тем, как продолжить свою работу, загрузчик операционной системы должен знать кое-что о конфигурации системного диска загрузки (Рис. 2-4). Совместимые с MS-DOS диски содержат структуру данных, ко- торая содержит эту информацию. Эта структура, известная как блок пара- метров BIOS (BIOS parameter block - BPB), содержится в том же секторе, что и загрузчик операционной системы. Из содержимого BPB загрузчик операционной системы вычисляет расположение корневого каталога диска первоначальной загрузки, для того, чтобы проверить, что первыми двумя точками входа в корневом каталоге являются IO.SYS и MSDOS.SYS. Для версий MS-DOS, начиная с 3.2, эти файлы также должны быть двумя первы- ми файлами в области данных и должны занимать непрерывный участок па- мяти. (Загрузчик операционной системы обычно не проверяет таблицу раз- мещения файлов (file allocatin table - FAT) на наличие IO.SYS и MSDOS.SYS, которые фактически хранятся в смежных секторах). См.: ПРОГ- РАММИРОВАНИЕ В СРЕДЕ MS-DOS: Структура MS-DOS: Запоминающие устройства MS-DOS. Далее, загрузчик операционной системы считывает сектора, содержа- щие IO.SYS и MSDOS.SYS, в непрерывную область памяти, расположенную сразу над таблицами BIOS (Рис. 2-5). (Другой метод состоит в использо- вании последней команды перехода загрузчика операционной системы сразу на вход IO.SYS и включение в IO.SYS программ, которые позволят IO.SYS загрузить MSDOS.SYS). И, наконец , если файл был загружен без каких-либо ошибок, заг- рузчик операционной системы передает управление IO.SYS, передавая ко- ординаты устройства первоначальной загрузки. Загрузчик операционной системы больше уже не нужен, и оперативная память, которую он занимал, может быть использована для других целей. 2.2. Системная инициализация MS-DOS (SYSINIT) Системная инициализация MS-DOS начинается после того, как загруз- чик операционной системы загрузил IO.SYS и MSDOS.SYS и передал управ- ление на начало IO.SYS. На все выполняемые до этого момента действия не существует стандартной процедуры загрузки, обеспечиваемой MS-DOS, хотя описываемая здесь процедура загрузки стала фактически стандартной для большинства машин с операционной системой MS-DOS. Однако с момента передачи управления IO.SYS MS-DOS использует свои стандартные процеду- ры. Файл IO.SYS делится на три модуля: * Резидентные драйверы устройств * Модуль инициализации базисной BIOS MS-DOS * Модуль системной инициализации SYSINIT -------------------¬ <---- FFFF:000FH (1 Мбайт) ¦ ¦ <---- FFFF:0000H ¦ BIOS ¦ ¦__________________¦ <---- F000:0000H ¦ ¦ ¦ Другие ПЗУ и ¦ ¦ оперативная ¦ ¦ память ¦ ¦__________________¦ <---- Вершина оперативной памяти ¦ ¦ (A000:0000H для IBM PC) ¦ Возможно свобод-¦ ¦ ная оперативная ¦ ¦ память ¦ ¦__________________¦ ¦ ¦ <---- Произвольное расположение ¦ Сектор начальной¦ ¦ загрузки ¦ ¦__________________¦ ¦ ¦ ¦ Свободная ¦ ¦ оперативная ¦ ¦ память ¦ +------------------+ <---- 0000:0600H ¦ ¦ ¦ Таблицы BIOS ¦ ¦ ¦ +------------------+ <---- 0000:0400H ¦ ¦ ¦ Вектора ¦ ¦ прерываний ¦ ¦ ¦ L------------------- <---- 0000:0000H Рис. 2-3. Загружаемый сектор первоначальной загрузки Два модуля инициализации обычно освобождают память после того, как MS-DOS полностью инициализирована и начал выполняться командный процессор; резидентные драйверы устройств остаются в памяти во время функционирования MS-DOS и поэтому размещаются в первой части файла IO.SYS, перед модулями инициализации. Модуль инициализации MS-DOS BIOS обычно выводит на дисплей сооб- щение о входе в систему и об авторских правах изготовителей оборудова- ния, которые разрабатывали IO.SYS. На IBM-совместимых машинах затем проверяются точки входов в таблицу прерываний для определения устрой- ств, найденных BIOS во время выполнения теста POST и, соответственно, актуализируется список резидентных драйверов устройств. Эта установка приводит обычно к удалению тех драйверов, которые не имеют соответст- -------------------¬ ¦ ¦ <---- Первый сектор на диске ¦ Сектор первона- ¦ ¦ чальной загрузки¦ ¦__________________¦ ¦ ¦ ¦ Резерв ¦ ¦ (необязательный)¦ ¦__________________¦ ¦ ¦ ¦ FAT #1 ¦ ¦__________________¦ ¦ ¦ ¦ FAT #2 ¦ ¦__________________¦ ¦ ¦ ¦ Корневой каталог¦ ¦__________________¦ ¦ ¦ ¦ IO.SYS ¦ ¦__________________¦ ¦ ¦ ¦ MSDOS.SYS ¦ +------------------+ ¦ ¦ ¦ Область данных ¦ ¦ ¦ ¦ ............... ¦ ¦ ¦ ¦ ¦ ¦__________________¦ Рис. 2-4. Конфигурация диска первоначальной загрузки вующего установленного оборудования. Программа инициализации может также модифицировать внутренние таблицы в драйверах устройств. Прог- раммы инициализации драйверов устройств позднее будут вызываться прог- раммой SYSINIT. На этом программы инициализации MS-DOS BIOS по сущест- ву заканчивают свою работу, и управление передается модулю SYSINIT. SYSINIT определяет старшие адреса оперативной памяти и копирует сам себя в эту область. Затем управление передается этой копии, и ко- пия продолжает инициализацию системы. Первый шаг состоит в перемещении MSDOS.SYS, который содержит ядро MS-DOS, в память, непосредственно следующую за резидентной частью IO.SYS, содержащей резидентные драйве- ры устройств. Это перемещение перекрывает первоначальную копию SYSINIT и, обычно, всю программу инициализации MS-DOS BIOS, которые больше уже не потребуются. Результирующее распределение памяти показано на рис. 2-6. -------------------¬ <---- FFFF:000FH (1 Мбайт) ¦ ¦ ¦ BIOS ¦ ¦__________________¦ <---- F000:0000H ¦ ¦ ¦ Другие ПЗУ и ¦ ¦ оперативная ¦ ¦ память ¦ ¦__________________¦ <---- Вершина оперативной памяти ¦ ¦ (A000:0000H для IBM PC) ¦ Возможно свобод-¦ ¦ ная оперативная ¦ ¦ память ¦ ¦__________________¦ ¦ ¦ <---- Произвольное расположение ¦ Сектор начальной¦ ¦ загрузки ¦ ¦__________________¦ ¦ ¦ ¦ Свободная ¦ ¦ оперативная ¦ ¦ память ¦ ¦__________________¦ ¦ ¦ ¦ MSDOS.SYS ¦ ¦__________________¦ ¦ ¦ <---- SYSINIT ¦ IO.SYS ¦ <---- MS-DOS BIOS (резидентные драйверы уст-в) ¦ ¦ +------------------+ <---- 0000:0600H ¦ ¦ ¦ Таблицы BIOS ¦ ¦ ¦ +------------------+ <---- 0000:0400H ¦ ¦ ¦ Вектора ¦ ¦ прерываний ¦ ¦ ¦ L------------------- <---- 0000:0000H Рис. 2-5. Расположение IO.SYS и MSDOS.SYS в памяти Затем SYSINIT вызывает программу инициализации, расположенную в перемещенном ядре MS-DOS . Эта программа выполняет внутреннюю началь- ную установку для ядра, включая установку соответствующих значений в вектора прерываний в диапазоне от 20H до 3FH. После этого программа инициализации ядра MS-DOS вызывает функцию инициализации каждого резидентного драйвера устройства для установки векторов каждого используемого устройством внешнего прерывания. Каждый драйвер дискового устройства возвращает указатель на BPB (блок пара- метров BIOS) соответствующего устройства. Эти BPB проверяются SYSINIT для нахождения наибольшего размера сектора, используемого любым из драйверов. (См.: ПРОГРАММИРОВАНИЕ В СРЕДЕ MS-DOS: Структура MS-DOS: Запоминающие устройства MS-DOS.) Далее программа инициализации ядра организует буфер секторов, равный размеру наибольшего найденного сек- тора и размещает драйвер устройства NUL в начало списка драйверов уст- ройств. -------------------¬ <---- FFFF:000FH (1 Мбайт) ¦ BIOS ¦ ¦------------------¦ <---- F000:0000H ¦ Другие ПЗУ и ¦ ¦ оперативная ¦ ¦ память ¦ ¦------------------¦ <---- Вершина оперативной памяти ¦ SYSINIT ¦ (A000:0000H для IBM PC) ¦------------------¦ ¦ Свободная ¦ ¦ оперативная ¦ ¦ память ¦ ¦------------------¦ ¦ Ядро MS-DOS ¦ ¦ (MSDOS.SYS) ¦ ¦------------------¦ ¦ ¦ ¦ MS-DOS BIOS ¦ ¦ (IO.SYS) ¦ <---- Резидентные драйверы устройств ¦ ¦ +------------------+ <---- 0000:0600H ¦ ¦ ¦ Таблицы BIOS ¦ ¦ ¦ +------------------+ <---- 0000:0400H ¦ ¦ ¦ Вектора ¦ ¦ прерываний ¦ ¦ ¦ L------------------- <---- 0000:0000H Рис. 2-6. Расположение SYSINIT и MSDOS.SYS в памяти после переме- щения Последним, перед возвращением в SYSINIT, оператором программы инициализации ядра является оператор, выдающий сообщение об авторских правах на систему MS-DOS. На этом заканчивается загрузка системной части MS-DOS, и SYSINIT может использовать любую функцию MS-DOS вместе с набором резидентных драйверов устройств. После этого SYSINIT пытается открыть файл CONFIG.SYS в корневом каталоге устройства первоначальной загрузки. Если файл не существует, то SYSINIT использует системные параметры по умолчанию; если файл отк- рыт, то SYSINIT читает его полностью в старшие адреса памяти и преоб- разовывает все символы в заглавные. Содержимое файла затем просматри- вается для выяснения установок, таких как число дисковых буферов, чис- ло входов в таблицах файлов и число входов в адресной таблице устройс- тва (в зависимости от специфических команд в файле). Эти структуры размещаются в памяти вслед за ядром MS-DOS (рис. 2-7). Затем SYSINIT последовательно просматривает текст CONFIG.SYS для определения необходимых устанавливаемых драйверов устройств и загружа- ет файлы устанавливаемых драйверов устройств в память после системных дисковых буферов и системных таблиц файлов и устройств. Файлы устанав- ливаемых драйверов устройств могут быть расположены в любом каталоге на любом устройстве, драйвер которого уже загружен. Для каждого уста- навливаемого драйвера, после того как файл драйвера устройства загру- жен в память, вызывается функция инициализации. Процедура инициализа- ции такая же, что и для резидентных драйверов устройств, за исключени- ем того, что SYSINIT использует адрес, возвращаемый самим драйвером устройства, для определения месторасположения в памяти следующего драйвера. См.: ПРОГРАММИРОВАНИЕ В СРЕДЕ MS-DOS: Настройка MS-DOS: Ус- танавливаемые драйверы устройств. Устанавливаемые драйверы устройств, подобно резидентным драйверам устройств, могут быть удалены при помощи SYSINIT, если программа ини- циализации драйвера устройства определит, что устройство не задейство- вано или не существует. Удаленный драйвер устройства не включается в список драйверов устройств. Устанавливаемые драйверы символьных уст- ройств замещают резидентные драйверы символьных устройств с теми же именами; устанавливаемые драйверы блочных устройств не замещают рези- дентные драйверы блочных устройств и назначаются устройствам, обозна- чения которых начинаются с букв, следующих за буквами, назначенными резидентным драйверам блочных устройств. Далее SYSINIT закрывает все открытые файлы и затем открывает три символьных устройства CON, PRN и AUX. Консоль (CON) используется для стандартного ввода, стандартного вывода и как стандартное устройство вывода сообщений об ошибках; PRN - это порт стандартного принтера (по умолчанию - LPT1); AUX является стандартным дополнительным портом (по умолчанию - COM1). Устанавливаемые драйверы устройств с этими именами будут замещать все соответствующие резидентные версии. 2.3. Запуск командного процессора Последней функцией SYSINIT является загрузка и выполнение прог- раммы командного процессора при помощи функции MS-DOS - EXEC. См.: ПРОГРАММИРОВАНИЕ В СРЕДЕ MS-DOS: Программирование для MS-DOS: Функция MS-DOS - EXEC. Оператор SHELL в CONFIG.SYS определяет имя программы командного процессора и его начальные параметры; в MS-DOS по умолчанию командный процессор - это COMMAND.COM. Программа командного процессора загружается в начало свободной памяти после устанавливаемых драйверов -------------------¬ <---- FFFF:000FH (1 Мбайт) ¦ BIOS ¦ ¦------------------¦ <---- F000:0000H ¦ Другие ПЗУ и ¦ ¦ оперативная ¦ ¦ память ¦ ¦------------------¦ <---- Вершина оперативной памяти ¦ ¦ (A000:0000H для IBM PC) ¦ SYSINIT ¦ ¦------------------¦ ¦ Свободная ¦ ¦ оперативная ¦ ¦ память ¦ ¦------------------¦ ¦ Устанавливаемые ¦ ¦ драйверы ¦ ¦ устройств ¦ ¦------------------¦ ¦ Блоки управле- ¦ ¦ ния файлами ¦ ¦------------------¦ ¦ Буферы ¦ ¦ дисков ¦ ¦------------------¦ ¦ Таблицы MS-DOS ¦ ¦------------------¦ ¦ Ядро MS-DOS ¦ ¦ (MSDOS.SYS) ¦ ¦------------------¦ ¦ MS-DOS BIOS ¦ ¦ (IO.SYS) ¦ <---- Резидентные драйверы устройств +------------------+ <---- 0000:0600H ¦ Таблицы BIOS ¦ +------------------+ <---- 0000:0400H ¦ Вектора ¦ ¦ прерываний ¦ L------------------- <---- 0000:0000H Рис. 2-7. Размещение таблиц и загруженных устанавливаемых драйве- ров устройств устройств или после последнего блока управления внутренним файлом MS-DOS, если не имеется устанавливаемых драйверов устройств (рис 2-8). 2.3.1. COMMAND.COM COMMAND.COM состоит из трех частей: * Резидентная часть * Модуль инициализации * Нерезидентная часть Резидентная часть обеспечивает завершение программ, запущенных при помощи COMMAND.COM, и выдает сообщения о критических ошибках. Она также ответственна за перезагрузку (в случае необходимости) нерезиден- тной части COMMAND.COM. Модуль инициализации вызывается только один раз резидентной частью COMMAND.COM. Первое, что он делает, это перемещает нерезидент- ную часть в старшие адреса памяти (сравните рис. 2-8 и рис. 2-9). За- тем он обрабатывает параметры, определенные в команде SHELL файла CONFIG.SYS, если таковые имеются. (См.: Команды пользователя: COMMAND.) Далее обрабатывается файл AUTOEXEC.BAT (если он существует), и, наконец, модуль инициализации передает управление обратно резидент- ной части COMMAND.COM, которая освобождает пространство, занимаемое модулем инициализации и нерезидентной частью. После этого перемещенная нерезидентная часть COMMAND.COM выводит пользователю MS-DOS подсказку и готова к обработке команд. Нерезидентная часть получает команду либо с консоли, либо из ко- мандного файла и выполняет ее. Команды делятся на три категории: * Внутренние команды * Командные файлы * Внешние команды Внутренние команды являются программами, содержащимися в COMMAND.COM и включают операции типа COPY или ERASE. Выполнение внут- ренних команд не приводит к перекрытию нерезидентной части. Внутренние команды состоят из ключевого слова, сопровождаемого иногда списком па- раметров, уточняющих действие команды. Командные файлы являются текстовыми файлами, которые содержат внутренние команды, внешние команды, директивы командных файлов и не- выполняемые комментарии. (См.: Команды пользователя: BATCH.) Внешние команды, которые фактически являются выполняемыми прог- раммами, хранятся в отдельных файлах с расширениями .COM или .EXE и включаются в дистрибутивные диски MS-DOS. (См.: ПРОГРАММИРОВАНИЕ В СРЕДЕ MS-DOS: Программирование для MS-DOS: Структура прикладной прог- раммы.) Эти программы вызываются по имени файла без расширения. (Вер- сии 3.x MS-DOS позволяют специфицировать полностью путь доступа к фай- лу, соответствующему внешней команде). Внешние команды загружаются командным процессором COMMAND.COM средствами функции MS-DOS - EXEC. Функция EXEC загружает программу в свободную область памяти, также называемой областью нерезидентных программ (transient program area - TPA), и затем передает ей управле- ние. Когда новая программа заканчивается, то управление возвращается к COMMAND.COM. Память, используемая программой, освобождается, если только программа не имела статус "завершиться-и-остаться-резидентной" (terminate-and-stay-resident - TSR). В этом случае часть памяти сохра- няется за резидентной частью программы. (См.: ПРОГРАММИРОВАНИЕ В СРЕДЕ MS-DOS: Настройка MS-DOS: TSR-утилиты .) После завершения программы резидентная часть COMMAND.COM просмат- -------------------¬ <---- FFFF:000FH (1 Мбайт) ¦ BIOS ¦ ¦------------------¦ <---- F000:0000H ¦ Другие ПЗУ и ¦ ¦ оперативная ¦ ¦ память ¦ ¦------------------¦ <---- Вершина оперативной памяти ¦ SYSINIT ¦ (А000:0000Н для IBM PC) ¦------------------¦ ¦ Свободная ¦ ¦ оперативная ¦ ¦ память ¦ ¦------------------¦ ¦ COMMAND.COM ¦ ¦ (временный) ¦ ¦------------------¦ ¦ COMMAND.COM ¦ ¦ (инициализация) ¦ ¦------------------¦ ¦ COMMAND.COM ¦ ¦ (резидентный) ¦ ¦------------------¦ ¦ Устанавливаемые ¦ ¦ драйверы ¦ ¦ устройств ¦ ¦------------------¦ ¦ Блоки управления ¦ ¦ файлами ¦ ¦------------------¦ ¦ Буферы дисков ¦ ¦------------------¦ ¦ Таблицы MS-DOS ¦ ¦------------------¦ ¦ Ядро MS-DOS ¦ ¦ (MSDOS.SYS) ¦ ¦------------------¦ ¦ MS-DOS BIOS ¦ ¦ (IO.SYS) ¦ <---- Резидентные драйверы устройств +------------------+ <---- 0000:0600H ¦ Таблицы BIOS ¦ +------------------+ <---- 0000:0400H ¦ Вектора ¦ ¦ прерываний ¦ L------------------- <---- 0000:0000H Рис. 2-8. Расположение COMMAND.COM после загрузки ривает память с целью определения: не является ли нерезидентная часть до сих пор занятой, потому что если программа была большой, она могла затереть нерезидентную часть памяти. Этот контроль выполняется путем -------------------¬ <---- FFFF:000FH (1 Мбайт) ¦ BIOS ¦ ¦------------------¦ <---- F000:0000H ¦ Другие ПЗУ и ¦ ¦ оперативная ¦ ¦ память ¦ ¦------------------¦ <---- Вершина оперативной памяти ¦ COMMAND.COM ¦ (A000:0000H для IBM PC) ¦ (временный) ¦ ¦------------------¦ ¦ Свободная ¦ ¦ оперативная ¦ ¦ память ¦ ¦------------------¦ ¦ COMMAND.COM ¦ ¦ (резидентный) ¦ ¦------------------¦ ¦ Устанавливаемые ¦ ¦ драйверы ¦ ¦ устройств ¦ ¦------------------¦ ¦ Блоки управления ¦ ¦ файлами ¦ ¦------------------¦ ¦ Буферы дисков ¦ ¦------------------¦ ¦ Таблицы MS-DOS ¦ ¦------------------¦ ¦ Ядро MS-DOS ¦ ¦ (MSDOS.SYS) ¦ ¦------------------¦ ¦ MS-DOS BIOS ¦ ¦ (IO.SYS) ¦ <---- Резидентные драйверы устройств +------------------+ <---- 0000:0600H ¦ Таблицы BIOS ¦ +------------------+ <---- 0000:0400H ¦ Вектора ¦ ¦ прерываний ¦ L------------------- <---- 0000:0000H Рис. 2-9. COMMAND.COM после перемещения сравнения хранимого значения размера нерезидентной части с вновь вы- численным. Если эти величины не совпали, то резидентная часть загружа- ет новую копию нерезидентной части из файла COMMAND.COM. Так же, как и COMMAND.COM, загружающий и выполняющий программу с помощью функции EXEC, так и сами программы могут загружать и выполнять другие программы, пока позволяют размеры системной памяти. Рис. 2-10 показывает типичную конфигурацию памяти в случае загрузки в память в одно и то же время нескольких прикладных программ. Активная задача,- последняя исполняемая,- обычно обладает полным контролем над системой, за исключением обработчиков аппаратных прерываний, которые получают управление всякий раз, когда аппаратное прерывание нуждается в обра- ботке. MS-DOS не является многозадачной операционной системой и, хотя несколько программ могут быть резидентными в памяти, только одна прог- рамма может быть активной в каждый момент времени. Стеко-подобная структура системы видна из рис 2-10. "Верхняя" программа является ак- тивной, следующая (нижерасположенная) программа продолжит свое выпол- нение, когда завершит свою работу верхняя, и так далее до тех пор, по- ка управление не вернется к COMMAND.COM. Исключением являются програм- мы, резидентные в оперативной памяти, остающиеся в памяти после своего завершения. В этом случае может стать активной программа, находящаяся в памяти "ниже", чем другая, хотя то ограничение, что активным может быть только один процесс, остается в силе. 2.3.2. Определяемая пользователем программа коман- дного процессора Директива SHELL в файле CONFIG.SYS может быть использована для замещения командного процессора, используемого по умолчанию (COMMAND.COM) на командный процессор, определяемый пользователем. Практически любая программа может быть использована в качестве систем- ного командного процессора, если она удовлетворяет требованиям исполь- зующихся по умолчанию обработчиков прерываний для Control-C и исключи- тельных ситуаций. Например, программа на рис. 2-11 может использовать- ся для превращения любой появляющейся прикладной программы в программу командного процессора следующим образом: когда прикладная программа завершается, SHELL.COM запускает ее вновь, создавая иллюзию, что прик- ладная программа является программой командного процессора. SHELL.COM устанавливает для функционирования сегментные регистры так, как это принято для .COM-файла, и уменьшает размер программного сегмента, делая его меньшим 1 Кбайта. Затем он инициализирует сегмент- ные значения для функции EXEC в таблице параметров, потому что .COM-файлы не могут устанавливать значения сегментов внутри программы. Векторы прерываний обработчиков Control-C и критической ошибки уста- навливаются равными адресу цикла основной программы, которая пытается загрузить новую программу командного процессора. Если операция EXEC завершилась неудачно, SHELL.COM печатает сообщение. Цикл повторяется все время, и SHELL.COM никогда не вернется в удаленный SYSINIT, кото- рый запустил SHELL.COM. ; SHELL.ASM Простая программа для запуска прикладной программы как ; программы командного процессора MS-DOS. Имя программы и ; начальные параметры должны быть установлены перед ас- ; семблированием программы SHELL ; ; Написана Уильямом Вонгом ; ; Создать SHELL.COM: ; ; C>MASM SHELL; ; C>LINK SHELL; ; C>EXE2BIN SHELL.EXE SHELL.COM -------------------¬ <---- FFFF:000FH (1 Мбайт) ¦ BIOS ¦ ¦------------------¦ <---- F000:0000H ¦ Другие ПЗУ и ¦ ¦ оперативная ¦ ¦ память ¦ ¦------------------¦ <---- Вершина оперативной памяти ¦ COMMAND.COM ¦ (A000:0000H для IBM PC) ¦ (временный) ¦ ¦------------------¦ ¦ Свободная ¦ ¦ оперативная ¦ ¦ память ¦ ¦------------------¦ ¦ Программа #3 ¦ ¦ (активная) ¦ ¦------------------¦ ¦ Программа #2 ¦ ¦------------------¦ ¦ Программа #1 ¦ ¦------------------¦ ¦ COMMAND.COM ¦ ¦ (резидентный) ¦ ¦------------------¦ ¦ Устанавливаемые ¦ ¦ драйверы ¦ ¦ устройств ¦ ¦------------------¦ ¦ Блоки управления ¦ ¦ файлами ¦ ¦------------------¦ ¦ Буферы дисков ¦ ¦------------------¦ ¦ Таблицы MS-DOS ¦ ¦------------------¦ ¦ Ядро MS-DOS ¦ ¦ (MSDOS.SYS) ¦ ¦------------------¦ ¦ MS-DOS BIOS ¦ ¦ (IO.SYS) ¦ <---- Резидентные драйверы устройств +------------------+ <---- 0000:0600H ¦ Таблицы BIOS ¦ +------------------+ <---- 0000:0400H ¦ Вектора ¦ ¦ прерываний ¦ L------------------- <---- 0000:0000H Рис. 2-10. Загрузка нескольких программ stderr equ 2 ; стандартная ошибка cr equ 0dh ; возврат каретки в ASCII lf equ 0ah ; пропуск строки в ASCII cseg segment para public 'CODE' ; ; -- Установка DS, ES, и SS:SP для выполнения как файл .COM ; assume cs:cseg start proc fat mov ax,cs ; установка регистров сегмента add ax,10h ; AX = сегментный, следующий за PCP mov ds,ax mov ss,ax ; установка указателя стека mov sp,offset_stk mov ax,offset_shell push cs ; занести в стек содержимое cs push ds ; занести в стек адрес сегмента push ax ; занести в стек адрес смещения ; командного процессора ret ; переход к командному процессору start endp ; ;-- Основная программа, выполняемая как .COM -- ; ;CS, DS, SS = cseg ;Исходное значение CS в вершине стэка ; assume cs:cseg,ds:cseg,ss:cseg seg_size equ (((offset last)-(offset start)) 10fh)/16 shell proc near pop es ; ES - адрес сегмента для осво- ; бождения памяти mov bx,seg_size ; BX - размер нового сегмента mov ah,4ah ; AH - модифицировать блок памяти int 21h ; освободить избыточную память mov cmd_seg,ds ; установка сегментов в mov fcb1_seg,ds ; блоке параметров для EXEC mov fcb2_seg,ds mov dx,offset main_loop mov ax,2528h ; AX - уст. адрес обработчика ; Control-C int 21h ; Уст.адрес обработчика рав- ; ным DS:DX mov dx,offset main_loop mov ax,2524h ; AX - уст. адрес обработчика ; критической ошибки int 21h ; Уст. адрес обработчика рав- ; ным DS:DX ; Замечание: DS равен CS main_loop: push ds ; Сохранить сегментные регистры push es mov cs:stk_seg,ss ; Сохранить указатель стека mov cs:stk_off,sp mov dx,offset pgm_name mov bx,offset par_blk mov ax,4b00h ; AX - EXEC/выполн. программу int 21h ; случай, если EXEC не отработал mov ss,cs:stk_seg ; Восстановить указатель стека mov sp,cs:stk_off pop es ; Восстанов. сегментные регистры pop ds jnc main_loop ; цикл, если программа запущена mov dx,offset load_msg mov cx,load_msg_length call print ; Вывод сообщения об ошибках mov ah,08h ; AH - читать без эхо int 21h ; Ждать любой символ jmp main_loop ; Выпонить цикл shell endp ; ;-- Print string -- ; ;DS:DX = adress of string ;CX = size ; print proc near mov ah,40h ; AH = запись в файл mov bx,stderr ; BX = идентификатор дескриптора ; файла. int 21h ; Печатать строку ret print endp ; ;-- Строки сообщений-- ; load_msg db cr,lf db 'Не могу загрузить программу',cr,lf db 'Для новой попытки - нажми любую клавишу',cr,lf load_msg_length equ $-load-msg ; ;-- Program data area ; stk_seg dw 0 ; указатель стека сегмента stk_off dw 0 ; сохранить область на время EXEC pgm_name db '\NEWSHELL.COM',0 ; Любая программа выполнится par_blk dw 0 ; использовать текущую среду dw offset cmd_line ; адрес командной строки cmd_seg dw 0 ; заполнить при инициализации dw offset fcb1 ; по умолчанию FCB #1 fcb1_seg dw 0 ; заполнить при инициализации dw offset fcb2 ; по умолчанию FCB #2 fcb2_seg dw 0 ; заполнить при инициализации cmd_line db 0,cr ; действительная командная строка fcb1 db 0 db 11 dup (' ') db 25 dup ( 0 ) fcb2 db 0 db 11 dup (' ') db 25 dup ( 0 ) dw 200 dup ( 0 ) ; область стека программы stk dw 0 last equ s ; последний используемый адрес cseg ends end start Рис.2-11. Пример простой программы, запускающей прикладную прог- рамму как командный процессор MS-DOS SHELL.COM - небольшая и не очень "интеллектуальная" программа. Она требует изменений и переработки, если меняется имя прикладной программы. Простым расширением SHELL (назовем его XSHELL) может стать установка имени прикладной программы и любых параметров в командной строке. SHELL должна после этого сделать синтаксический анализ имени прикладной программы и содержимого двух блоков FCB, необходимых для функции EXEC. Командная строка в CONFIG.SYS для запуска этого команд- ного процессора должна быть следующей: SHELL=XSHELL \SHELL\DEMO.EXE PARAM1 PARAM2 PARAM3 SHELL.COM не устанавливает новую среду, а просто использует ту, что ей передается. Уильям Вонг Глава 3. Запоминающие устройства в MS-DOS Доступ прикладных программ к данным, хранящимся на запоминающих устройствах MS DOS, осуществляется посредством файловой системы, кото- рая входит в состав ядра MS DOS . Обращение к запоминающим устройст- вам, называемым также блочными устройствами, осуществляется драйверами двух типов: резидентными драйверами блочных устройств, содержащимися в IO.SYS, и инсталлируемыми драйверами блочных устройств, загружаемыми из индивидуальных файлов при загрузке MS DOS (см. ПРОГРАММИРОВАНИЕ В СРЕДЕ MS DOS: структура MS DOS; компоненты MS DOS; установка MS DOS; устанавливаемые драйверы устройств). MS DOS может работать практически с любым носителем данных или методом записи, различными вариациями запоминающих устройств, если имеется соответствующий драйвер устройства. MS DOS необходимо только знать размер сектора и максимальное число секторов для устройства; за- тем драйвером устройств осуществляется соответствующее преобразование логического номера сектора в физический адрес. Информация о числе го- ловок, дорожек и т.п. необходима только тем программам, которые расп- ределяют логические устройства в этих границах (см. ниже СТРУКТУРА РАЗДЕЛА ДИСКА). Наиболее известным блочным устройством, очевидно, является ус- тройство гибкого диска (floppy-disk drive), за которым следует более быстрое устройство фиксированного диска (fixed-disk drive). К другим устройствам MS DOS относятся виртуальные диски, энергонезависимые псевдодиски, перемещаемые жесткие диски, магнитоленточные устройства и ПЗУ на компактных (оптических) дисках (CD ROM drives). При наличии со- ответствующего драйвера MS DOS может разместить файловую систему на любом из этих устройств (за исключением устройств, доступных только для чтения, например, ПЗУ на компактных дисках). В данной статье описывается структура файловой системы на гибких и жестких дисках; прежде всего рассматривается физическая структура диска, а затем - логическая структура файловой системы. Такая схема дается на примере фиксированного диска IBM PC. 1. Структура диска в MS DOS Структуру диска MS DOS можно рассматривать в следующих аспектах: - физическая структура устройства; - логическая структура устройства; - логическая структура блока; - файловая система MS DOS. Физическая структура диска описывается в терминах секторов, доро- жек и головок. Логическая структура устройства также выражается в тер- минах секторов, дорожек и головок; кроме того, она определяет, как ло- гическое устройство отображается на физическое. Разделенное физическое устройство содержит множество логических; неразделяемое физическое ус- тройство содержит только одно логическое. Каждое логическое устройство включает логическую структуру блока, используемую MS DOS для реализа- ции файловой системы. Ниже описываются различные структуры диска в MS DOS (см. также ПРОГРАММИРОВАНИЕ В СРЕДЕ MS DOS: программирование для MS DOS; управление файлами и записями, каталоги диска и метки тома). 1.1. Схема физического блочного устройства Двумя основными способами физической реализации блочных устройств являются виртуальные диски в оперативной памяти и вращающиеся магнит- ные устройства, такие как гибкие и фиксированные диски. Оба вида уст- ройств имеют фиксированный объем памяти на фиксированном количестве одинаковых по размеру секторов с произвольным доступом. 1.1.1. Виртуальные диски Виртуальный диск - это блочное устройство, секторы которого пос- ледовательно отображаются на ОЗУ. Таким образом, виртуальный диск рас- сматривается как большое множество последовательно пронумерованных секторов, адреса которых вычисляются простым умножением номера сектора на его размер, после чего прибавляется базовый адрес буфера секторов виртуального диска. Доступ к данным является быстрым и эффективным, а время доступа к любому сектору является фиксированным, что делает вир- туальный диск наиболее быстрым из имеющихся блочных устройств. Однако виртуальные диски имеют существенные недостатки. Во-первых, они явля- ются энергозависимыми; их содержимое может быть безвозвратно утеряно при прекращении подачи электроэнергии (хотя существует особый вид вир- туального диска - энергонезависимый виртуальный диск, который включает систему снятия резервной копии на батареях, обеспечивающую сохранность информации при отключении электроэнергии). Во-вторых, виртуальные дис- ки являются непереносимыми. 1.1.2. Физические диски Системы на гибких и фиксированных дисках, с другой стороны, хра- нят информацию на вращающихся пластинах, покрытых специальным магнит- ным веществом. Диск вращается на устройстве с большой скоростью - при- мерно 300 оборотов в минуту для гибких дисков и 3600 об/мин для фикси- рованных дисков. (Термин "фиксированный" относится не к движению носи- теля данных, а означает, что носитель постоянно встроен в устройство). Фиксированные диски называют еще "жесткими", т.к. сам диск обычно изготавливается из твердого материала, например, пластика. Элемент преобразователя, называемый головкой чтения-записи, используется для чтения и записи очень маленьких магнитных областей на вращающемся маг- нитном носителе. Эти магнитные области ведут себя, как небольшие маг- нитные бруски с северным и южным полюсами. Магнитные области носителя могут быть логически направлены к одному из этих полюсов - ориентация на один полюс интерпретируется как специфическое бинарное состояние (1 или 0), а ориентация на другой полюс - как противоположное бинарное состояние. Изменение в направлении ориентации (и, следовательно, изме- нение бинарного значения) между двумя смежными областями называется изменением направления потока, и плотность конкретного диска может быть измерена числом областей на один дюйм, которые с большой вероят- ностью могут изменить направление потока. Более высокая плотность этих областей способствует повышению емкости диска. Магнитная индукция кон- кретной системы зависит от механики устройства, характеристики головки чтения-записи и магнитных свойств носителя. С помощью головки чтения-записи может кодироваться цифровая ин- формация на диске с использованием различных средств записи, включаю- щих модуляцию частоты (frequence modulation - FM), модифицированную модуляцию частоты (modified frequence modulation - MFM), ограниченное кодирование переменной длины (run length limited (RLL) encoding) , расширенное кодирование переменной длины (advanced run length limited - (ARLL) encoding) . Каждый последующий метод кодирования обеспечивает двойную плотность записи закодированных данных по сравнению с предыду- щим. 1.1.3. Дорожки Головка чтения-записи читает и записывает данные на тонкую по- лоску диска, называемую дорожкой, которая расположена на диске в виде окружности (рис.3.1). Стандартные 5-дюймовые гибкие содержат либо 40 (0-39), либо 80 (0-79) дорожек на одной стороне. Одинаково нумеруемые дорожки на каждой стороне двустороннего диска различаются по номеру головки чтения/записи, используемой для доступа к дорожке. Например, дорожка 1 на верхней стороне диска обозначается как головка 0, дорожка 1; дорожка 1 на нижней стороне диска обозначается как головка 1, до- рожка 1. Дорожки могут представлять собой либо спирали, как на фонограм- мах, либо концентрические окружности. В первом типе дорожек сохраня- ется одинаковое количество секторов на каждой дорожке (см. ниже "Сек- торы") и вращение происходит с постоянной угловой скоростью (constant angular velocity - CAV). Во втором типе дорожек обеспечивается одина- ковая плотность записи на всей поверхности диска; таким образом, рас- положенные у центра диска дорожки содержат меньше секторов, чем до- рожки, находящиеся возле внешней границы диска. Этот тип диска враща- ется с различной скоростью, чтобы обеспечить необходимую скорость для магнитной головки, движущейся с постоянной линейной скоростью (constant linear velocity - CLV). Рис.3-1. Физическая структура 5,25-дюймового гибкого диска типа CAV с 9 секторами На большинстве компьютеров с MS DOS применяются диски типа CAV, хотя диск типа CLV может содержать большее количество секторов, ис- пользуя тот же тип устройства. Объем памяти является различным, пос- кольку ограничивающим факторов является плотность потока на данном ус- тройстве, а диск CAV должен содержать одинаковое количество областей магнитного потока на каждом секторе как в центре диска, так и по его периметру. Таким образом, секторы вблизи периметра диска не используют всей мощности устройства и головок, так как пространство, зарезервиро- ванное для каждой области магнитного потока, больше у периметра диска, чем у его центра. Несмотря на больший объем памяти, диски CLV (напри- мер, ПЗУ на компактных дисках CO RAM) обладают, к сожалению более низ- кой скоростью доступа, чем диски CAV, из-за постоянной потребности в точном регулировании скорости двигателя по мере продвижения головки от дорожки к дорожке. Поэтому диски CAV являются более предпочтительными для систем MS DOS. 1.1.4. Головки внешних устройств Простые дисковые системы включают единственный диск, или пласти- ну, и используют одну или две стороны этой пластины, более сложные системы, такие как фиксированные диска, используют многочисленные пластины. Дисковые системы, использующие две стороны диска, имеют по одной головке чтения/записи для каждой стороны; эти головки располага- ются над дорожкой для чтения или записи информации с помощью механизма позиционирования, как например, соленоид или сервомотор. Головки обыч- но движутся в унисон, используя один механизм движения головок; таким образом в системе с двусторонними дисками головки на противоположных сторонах пластины получают доступ к одной и той же логической дорожке на каждой стороне пластины, связанной с одной головкой (можно повысить производительность путем увеличения числа головок, при котором каждой дорожке будет соответствовать одна головка; при этом устраняется меха- низм позиционирования. Однако из-за высокой стоимости такие системы с множеством головок обычно встречаются только на высокопроизводительных мини- и больших ЭВМ). Множество одинаково пронумерованных дорожек на двух сторонах пластины (или на всех сторонах всех пластин в системе, использующей много пластин) называется цилиндром. Диски обычно разделяются на части в соответсвии с цилиндрами. До- рожки и цилиндры могут иметь одинаковое значение; однако термин "до- рожка" используется для определения концентрической окружности, вклю- чающей определенное число секторов на одной стороне одной пластины, тогда как термин "цилиндр" относится к множеству одинаково пронумеро- ванных дорожек на устройстве (рис. 3-2). Рис.3-2. Дорожки и цилиндры в системе с фиксированным диском 1.1.5. Секторы Каждая дорожка разделяется на равные части, называемые секторами. Размер сектора равен степени 2 и обычно превышает 128 Б - чаще всего равен 512 Б. Гибкие диски могут быть либо с жесткой, либо с программной раз- меткой в зависимости от дискового устройства и среды передачи данных. Жесткая разметка диска осуществляется посредством множества небольших отверстий возле центра диска, которые указывают на начало каждого сек- тора; эти отверстия читаются с помощью пары фотоэлемент/диод светоиз- лучения (LED), встроенных в дисковое устройство. Программная разметка дисков осуществляется посредством магнитных отметок начала каждого сектора при форматировании диска. Диск с программной разметкой имеет единственное отверстие вблизи центра диска (см. рис. 3-1), которое указывает на расположение сектора 0, что необходимо знать при формати- ровании диска или при обработке обнаруженной ошибки; это отверстие также читается с помощью пары фотоэлемент/диод светоизлучения. Фикси- рованные диски используют особый метод программной разметки (см. ниже). Гибкий диск с жесткой разметкой не может использоваться на дис- ковом устройстве, предназначенном для гибких дисков с программной раз- меткой (и наоборот). Кроме фиксированного числа байтов данных, оба типа секторов пред- полагают включение определенного количества дополнительной информации для каждого сектора, например, сведений об исправлении ошибок и иден- тификации сектора. Структура каждого сектора определяется в процессе форматирования. Стандартные фиксированные диски и 5,25-дюймовые гибкие диски обычно содержат от 8 до 17 физических секторов на одной дорожке. Сек- торы нумеруются с единицы. Каждый сектор идентифицируется уникальным образом посредством полной спецификации головки чтения/записи, номера цилиндра и номера сектора. Для доступа к определенному сектору кон- троллер дискового устройства перемещает все головки к нужному ци- линдру, а затем активизирует соответствующую головку для осуществления операции чтения или записи. Головки чтения/записи позиционируются механически, используя один или два аппаратных метода. Первый метод, применяемый для гибких дис- ков, реализует сервомеханизм "разомкнутого цикла" (open-loop), при ко- тором программа вычисляет, где должны находиться головки, а аппаратура их туда перемещает.(Сервомеханизм - это устройство, которое может пе- ремещать соленоид или поддерживать его в фиксированном положении). Система разомкнутого цикла не использует механизма обратной связи для определения правильности позиционирования головок - аппаратура просто перемещает головки к требуемой позиции и возвращает код ошибки, если не была получена ожидаемая информация. Механизм позиционирования для устройств с гибкими дисками является практически одинаковым, так как, если способ позиционирования головок на двух устройствах отличается, диски, записанные на одном устройстве, не смогут быть прочитаны на другом. В большинстве систем с фиксированным диском применяют второй ме- тод - сервомеханизм "замкнутого цикла" (closed-loop), при котором ре- зервируется одна сторона пластины для позиционирования информации. Эта информация, указывающая на расположении дорожек и секторов, записыва- ется на диск на заводе при сборке устройства. Позиционирование головок чтения/записи в системе с замкнутым циклом осуществляется в два этапа: во-первых, набор головок перемещается к примерному адресу операции чтения/записи; затем контроллер диска читает служебную информацию, сравнивает ее с предполагаемым расположением и соответственно коррек- тирует позицию головки. В результате этого подхода увеличивается ско- рость доступа, а также объем диска, так как позиционирование становит- ся более точным, а расстояние между дорожками, следовательно, стано- вится меньше. Поскольку "серво-пластина" обычно хранит информацию о позиционировании на одной стороне, а данные - на другой, многие систе- мы присваивают нечетные номера головкам чтения/записи данных. 1.1.6. Чередование Диски MS DOS типа CAV описываются в байтах в пределах сектора, секторах в пределах дорожки, а также определяются числом цилиндров и головок чтения/записи. Общее время доступа определяется тем, насколько быстро вращается диск ( время вращения - rotational latency) и как быстро перемещаются головки от дорожки к дорожке (время движения от дорожки к дорожке - track-to-track latency). На большинстве фиксированных дисков секторы на диске пронумеро- ваны логически и физически так, что логически последовательные секторы не являются физически смежными (рис.3-3). Основным принципом является то, что поскольку контроллер не может завершить обработку одного сек- тора прежде, чем логически следующий за ним не будет находится под го- ловкой чтения/записи, то логически пронумерованные секторы должны быть расположены вокруг дорожки. Такое расположение секторов называется смещенным (skewing), или проще говоря, чередующимся. Чередование типа 2:1 предполагает такое расположение логически последовательных секто- ров при котором между ними находится один дополнительны сектор; при чередовании типа 3:1 между ними располагаются два дополнительных сек- тора. При более медленном контроллере диска требуется больший диапазон чередования. Чередование типа 3:1 означает, что для чтения всех секто- ров на дорожке по порядку номеров необходимо сделать три оборота диска. Рис.3-3. Чередование типа 3:1 Одним из методов повышения производительности фиксированного диска является уменьшение коэффициента чередования. Для этого обычно требуется специальная сервисная программа, а также повторное формати- рование диска в соответствии с новой структурой. Очевидно, что чередо- вание типа 1:1 является наиболее эффективным при условии, что контрол- лер диска сможет работать с такой скоростью. Типичным чередованием для IBM PC/AT и стандартного для нее фиксированного диска и контроллера является 3:1, однако на PC/AT могут применяться контроллеры диска, способные обрабатывать чередование типа 1:1. Все гибкие диски на ком- пьютерах с MS DOS используют коэффициент чередования 1:1. 1.2. Структура распределения разделов диска По некоторым причинам, большие блочные физические устройства, та- кие как фиксированные диски, часто логически разделяются на логические блочные устройства меньшего размера (рис.3-4). Например, такое разде- ление позволяет использовать устройство между различными операционными системами. Разделение диска также можно использовать для обеспечения размера каждого логического устройства в рамках ограничения PC DOS, составляющего 32 МВ (существенно для фиксированных дисков). MS DOS позволяет иметь на диске максимум четыре раздела. Разделенное на части блочное устройство имеет таблицу описания разделов, находящуюся в одном из секторов в начале диска. Эта таблица указывает на физическое расположение логических блочных устройств (даже на диске с единственным разделом обычно имеется такая таблица). Рис.3-4. Разделение диска на части В соответствии со стандартом разбиения диска в MS DOS, первый фи- зический сектор фиксированного диска содержит таблицу описания разде- лов и программу начальной загрузки, предназначенную для проверки таб- лицы описания разделов при начальной загрузке разделов и передачи ему управления. Таблица описания разделов, расположенная в конце первого физического сектора на диске, может содержать максимум четыре входа: _____________________________________________________________________ Смещение от начала Размер | сектора (в байтах) Описание | ____________________________________________________________________| | 01BEH 16 Раздел #4 | 01CEH 16 Раздел #3 | 01DEH 16 Раздел #2 | 01EEH 16 Раздел #1 | 01FEH 2 Признак:АА55Н | | --------------------------------------------------------------------- Разделы расположены в обратном порядке. Каждый 16-байтовый вход одержит следующую информацию: _____________________________________________________________________ Смещение от начала Размер | сектора (в байтах) Описание | ____________________________________________________________________| | 00H 1 Индикатор начальной загрузки | 01H 1 Признак начала | 02H 1 Начальный сектор | 03H 1 Начальный цилиндр | 04H 1 Системный индикатор | 05C 1 Признак конца | 06D 1 Конечный сектор | 07B 1 Конечный цилиндр | 08H 4 Начальный сектор | (относительно начала диска) | 0CH 4 Количество секторов в разделе | | --------------------------------------------------------------------- Индикатор начальной загрузки равен нулю для незагружаемого раз- дела и 80Н для загружаемого (активного) раздела. Фиксированный диск может иметь только один загружаемый раздел. При загрузке какого-либо раздела такие программы, как FDISK, устанавливают индикаторы начальной загрузки для всех остальных разделов в 0. (см. главу КОМАНДЫ ПОЛЬЗОВАТЕЛЯ:FDISK). Системными индикаторами являются: --------------------------------------------------------------------- Код Значение | --------------------------------------------------------------------- 00Н Неопределено | 01Н MS DOS, 12-бит FAT | 04Н MS DOS, 16-бит FAT | --------------------------------------------------------------------- Сектор начальной загрузки для каждого раздела расположен в начале раздела, который определяется признаком начала, номерами начального сектора и начального цилиндра. Эта информация, хранящаяся в таблице описания полей в этом порядке, загружается в регистры DX и CX с по- мощью загрузчика базовой системы ввода/вывода на ПЗУ персональной ЭВМ ( ROM BIOS loader routine) при включении или рестарте машины. Также отмечается начальный сектор раздела относительно начала диска. Признак конца, номера конечного сектора и цилиндра также включены в таблицу описания разделов и определяют последний доступный сектор в данном разделе. Общее число секторов в разделе определяется как разность между номерами начального и конечного цилиндра, умноженная на число секторов в цилиндре. Версии MS DOS от 2.0 до 3.2 позволяют иметь только один раздел с MS DOS на разделенном устройстве. Применялись различные драйверы ус- тройств, использующие другую таблицу описания разделов, что позволяет устанавливать больше одного раздела с MS DOS, однако вторичные разделы с MS DOS обычно доступны только посредством инсталлируемого драйвера устройства, который знает об этом изменении (даже с дополнительными разделами с MS DOS фиксированный диск может иметь только один загружа- емый раздел). 1.3. Структура файловой системы Доступ к блочным устройствам осуществляется по секторам. Ядро MS DOS посредством драйвера устройства рассматривает блочное устройство как логический конечный массив секторов и предполагает, что этот мас- сив содержит допустимую в MS-DOS файловую организацию. Драйвер устройства, в свою очередь, преобразует запрос MS DOS на логический сектор в физический адрес блочного устройства. Первоначальная файловая система MS DOS записана в память с по- мощью программы MS DOS FORMAT (см.главу USER COMMANDS: FORMAT). Общая структура файловой системы показана на рис. 3-5. Сектор начальной загрузки всегда расположен в начале раздела. Он содержит идентификацию ОЕМ , программу-загрузчик и блок параметров BIOS (BPB) с информацией об устройстве; затем следует необязательная область зарезервированных секторов (см.ниже раздел СЕКТОР НАЧАЛЬНОЙ ЗАГРУЗКИ). Зарезервированная область не имеет специального назначения, однако ОЕМ может потребовать более сложной программы-загрузчика и по- местить ее в эту область. Таблицы размещения файлов (FAT) указывают на расположение области файлов данных; корневой каталог содержит фиксиро- ванное число входов, а область файлов данных включает файлы данных, файлы подкаталогов и свободные секторы данных. _______________________________________________________ |Идентификация ОЕМ, блок параметров BIOS, программа- | |загрузчик, зарезервированная область | |______________________________________________________| | Таблица размещения файлов (FAT) | |______________________________________________________| | Возможные дополнительные копии FAT | |_____________________________________________________ | | | | | | | | Корневой каталог диска | | | | _________________________________----------------| ------ | __________________ |______-------------------------------- | | | | Область файлов | |______________________________________________________| Рис.3-5. Файловая система MS DOS Все описанные выше области - сектор начальной загрузки, FAT, кор- невой каталог и область файлов данных - имеют фиксированный размер; это означает, что они не изменяются после того, как программа FORMAT определила среду данных. Размер каждой из этих областей зависит от различных факторов. Например, размер FAT пропорционален области файлов данных. Размер корневого каталога обычно зависит от типа устройств; односторонний гибкий диск может иметь 64 входа, двусторонний гибкий диск - 1126, а фиксированный диск - 256.(Драйверы виртуальных дисков такие, как RAMDRIVE.SYS и некоторые реализации программы FORMAT позво- ляют специфицировать число входов каталога). Область файлов данных описывается в терминах кластеров. Кластер определяется как фиксированное число смежных секторов. Размер сектора и размер кластера должны быть равны степени 2. Размер сектора обычно составляет 512 байт, а размер кластера - 1, 2 или 4 Кбайт, однако воз- можны секторы и кластеры большего размера. Ниже приведены типичные размеры кластеров, используемых в MS DOS : Вообще говоря, кластеры большего размера используются для фикси- рованных дисков большего размера. Хотя кластеры меньшего размера дела- ют их расположение пространственно более эффективным, кластеры боль- шего размера являются обычно более эффективными для произвольного и последовательного доступа, особенно если кластеры одного файла распо- ложены непоследовательно. Таблица размещения файлов содержит по одному входу для каждого кластера в области файлов данных. Дублирование секторов в кластере также уменьшит вдвое число входов FAT для данного раздела (см. ниже пункт Таблица размещения файлов). _____________________________________________________________________ Тип диска Размер кластера Размер кластера | (в секторах) (в байтах ) * | _____________________________________________________________________ Односторонний гибкий диск 1 512 | Двусторонний гибкий диск 2 1024 | Фиксированный диск РС/АТ 4 2048 | Фиксированный диск РС/ХТ 8 4096 | Другие фиксированные диски 16 8192 | Другие фиксированные диски 32 16384 | --------------------------------------------------------------------- Предполагается, что размер сектора равен 512 байт 1.3.1. Сектор начальной загрузки Сектор начальной загрузки (рис.3-6) содержит блок параметров BIOS (BPB), программу-загрузчик и некоторые другие данные полезные для драйверов устройств. BPB описывает некоторое число физических парамет- ров устройства, а также расположение и размер других областей на ус- тройстве. Драйвер устройства, при соответствующем запросе, передает MS DOS информацию о BPB, так что MS DOS может определить конфигурацию диска. На рис.3-7 показан шестнадцатеричный дамп реального сектора на- чальной загрузки. Первые три байта сектора начальной загрузки , пока- занные на рис.3-7, должны содержать E9H 2CH 00H, если используется длинная передача управления (jump) вместо короткой ( как в ранних вер- сиях MS DOS ). Последние два байта сектора 5511 и АА11 содержат фикси- рованное значение, используемое программой-загрузчиком для проверки правильности сектора начальной загрузки. Информация ВРВ, содержащаяся в байтах с ОВН по 17Н, указывает, что: сектор включает 512 байт, в кластере два сектора; имеется один зарезервированный сектор (для сектора начальной загрузки), 2 FAT'а, 112 входов в корневой каталог; диск содержит 1440 секторов, F9H дескрипторов устройств; FAT включает 3 сектора. Следующая за BPB дополнительная информация указывает, что в до- рожке содержится 9 секторов, имеется 2 головки чтения/записи и 0 неви- димых секторов. Дескриптор носителя данных, указываемый в ВРВ и в первом байте каждой FAT, используется для описания типа носителя, находящегося в данный момент на устройстве. Совместимые с IBM носители данных имеют следующие дескрипторы: ______________________________________________________ 00H | E9 XX XX или EB XX 90 | |------------------------------------------------------| 03H | Имя и версия ОЕМ (8 байт) | | | |______________________________________________________|_____ 0BH | Число байтов в секторе (2 байта) | | |______________________________________________________| | | | | 0DH | Число секторов на устройстве (1 байт) | | |______________________________________________________| | | | | 0EH | Число резервных секторов - нумерация с 0 (2 байта) | | |______________________________________________________| | | | | 10H | Число FAT (1 байт) | | |______________________________________________________| | | | | 11H | Число входов в корневом каталоге (2 байта) | | |______________________________________________________| | | | BPB 13H | Общее число секторов на логическом томе (2 байта) | | |______________________________________________________| | | | | 15H | Дескриптор носителя данных (1 байт) | | |______________________________________________________| | | | | 16H | Число секторов в FAT (2 байта) | | |______________________________________________________|____| | | 18H | Число секторов на дорожке (2 байта) | |______________________________________________________| | | 1AH | Число головок (2 байта) | |______________________________________________________| | | 1CH | Число невидимых секторов (2 байта) | |______________________________________________________| | | 1EH | | | ПРОГРАММА-ЗАГРУЗЧИК | | | |______________________________________________________| Рис.3-6. Структура сектора начальной загрузки MS DOS Байты с ОВН по 17Н содержат блок параметров BIOS (BPB) 0 1 2 3 4 5 6 7 8 9 A B C D E F 0000 EB 2D 90 20 20 20 20 20-20 20 20 00 02 02 01 00 ................. 0010 02 70 00 A0 05 F9 03 00-09 20 22 00 00 00 00 00 ................. 0020 00 0A 00 00 DF 02 25 02-09 2A B8 50 F6 02 FA 00 ................. 0030 BB C0 07 8E D8 BC 80 7C-33 C0 8E C0 F8 02 01 00 ................. . . . . . . . . . 0180 OA 44 69 73 5B 20 42 48-65 20 48 61 69 65 27 00 .Disk Boot.Failu. 0190 72 65 0D 0A 0D 0A 0A 4E-6F 20 53 79 73 74 65 60 re....Non-System. 01A0 20 64 69 73 6B 20 6F 72-20 64 69 73 6B 20 01 72 .disk or disk er 01B0 72 6F 72 0D 0A 52 65 70-60 61 63 65 20 61 62 64 .ror..Replace..and 01C0 20 70 72 65 73 73 20 61-6E 79 20 6B 65 79 20 77 .press.any key.w. 01D0 68 65 6E 20 72 65 61 64-79 79 0D 0A 00 00 00 00 .hen .ready...... 01E0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................. 01F0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 55 AA ................. Рис.3-7. Шестнадцатеричный дамп сектора начальной загрузки MS DOS _____________________________________________________________________ Дескриптор Тип носителя Версии MS DOS | --------------------------------------------------------------------| OF8H Фиксированный диск 2.3 | OF0H 3,5-дюймовый, 2-сторонний, 18-секторный 3.2 | OF9H 3,5-дюймовый, 2-сторонний, 9-секторный 3.2 | OF9H 5,25-дюймовый, 2-сторонний, 15-секторный 3.x | OFCH 5,25-дюймовый, 1-сторонний, 9-секторный 2.x,3.x | OFDH 5,25-дюймовый, 2-сторонний, 9-секторный 2.x,3.x | OFEH 5,25-дюймовый, 1-сторонний, 8-секторный 1.x,2.x,3.x | OFFH 5,25-дюймовый, 2-сторонний, 8-секторный 1.x(кроме 1.0)| OFEH 8-дюймовый, 1-сторонний, одинарной плотности 2.3 | OFDH 8-дюймовый, 2-сторонний, одинарной плотности | OFEH 8-дюймовый, 1-сторонний, двойной плотности | OFDH 8-дюймовый, 2-сторонний, двойной плотности | ____________________________________________________________________| 1.3.2. Таблица размещения файлов Таблица размещения файлов представляет схему размещения файлов в дисковой памяти посредством указания того, какие кластеры и в каком порядке включаются в каждый файл. Для того, чтобы MS DOS могла опреде- лить местоположение файла, описание данного файла в каталоге содержит номер его начального входа в FAT. Этот вход FAT в свою очередь, вклю- чает номер входа следующего кластера, если файл состоит более чем из одного кластера, либо номер последнего кластера, если файл содержит единственный кластер. Файл, состоящий из 10 кластеров, должен иметь 10 входов в FAT и 9 связей между входами FAT(множество связей для одного файла называется цепочкой - (chain)). Дополнительные копии FAT являются резервными и используются в случае повреждения первичной FAT; типичные гибкие и жесткие диски со- держат обычно 2 FAT. Эти таблицы располагаются последовательно за сек- тором начальной загрузки, а между ними иногда имеется резервная об- ласть. Как правило, MS DOS использует первичную FAT, однако, при появ- лении в ней изменений корректируются все таблицы. Кроме того, MS DOS сравнивает все таблицы при первом обращении к диску, чтобы убедиться, что они соответствуют друг другу. MS DOS поддерживает два типа FAT: один использует 12-битовые ссылки; другой применяется в версии 3.0 для включения в большие фикси- рованные диски более 4087 кластеров и использует 16-битовые ссылки. Два первых входа FAT всегда резервируются и содержат копию дес- криптора носителя данных (1 байт) и два (для 12-битовой FAT) или три (для 16-битовой FAТ) байты OFFH, как показано на примере следующих дампов первых 16 байтов FAT: 12-битовая FAT: F9 FF FF 03 40 00 FF 6F-00 07 F0 FF 00 00 00 00 16-битовая FAT: F8 FF FF FF 03 00 40 00-FF FF 06 00 07 00 FF FF Остальные входы FAT находятся во взаимно-однозначном соответствии с кластерами в области файлов данных. Состояние каждого кластера отме- чается соответствующим значением в FAT (программа FORMAT первоначально помечает вход FAT для каждого кластера, как свободный). Состояние кластера может принимать одно из следующих значений: Если вход FAT содержит ненулевое значение, соответствующий клас- тер уже занят. Свободный кластер можно найти, сканируя FAT с начала до обнаружения первого нулевого значения. Дефектные кластеры обычно иден- тифицируются в процессе форматирования. На рис.3-8 изображена типичная цепочка FAT. Свободные входы FAT содержат нулевое значение ссылки; единица, как значение ссылки, никогда не используется. Таким образом, первым номером ссылки, связанным с первым доступным кластером в области фай- лов данных, является 2; этот номер относится к первому физическому кластеру в области файлов данных. На рис.3-9 показана связь между фай- лами, входы FAT и кластеры в области файлов данных. Не существует логического различия между обработкой 12-битовых и 16-битовых входов FAT; различия относятся только к памяти и методам доступа. Поскольку процессор 8086 особенно предназначен для эффектив- ной обработки 8- или 16-битовых величин, то процедура доступа для 12-битовой FAT является более сложной, чем для 16-битовой (см. рис. 3-10 и 3-11). _____________________________________________________________________ 12-битовый 16-битовый Значение | --------------------------------------------------------------------| 000H 0000H Свободный кластер | 001H 0001H Код не используется | FF0-FF6H FFF0-FFF6H Резерв | FF7H FFF7H Дефектный кластер | (не используется) | FF8-FFFH FFF8-FFFFH Последний кластер в | файле | Все другие значения Ссылка на следующий | кластер в файле | ____________________________________________________________________| Вход FAT 0 1 2 3 4 5 6 7 8 9 ___________________________________________________________________ | FFDH| FFFH| 003H| 005H| FF7H| 006H| FFFH| 000H| 000H| 000H| | 4093| 4095| 3 | 5 | 4087| 6 | 4095| 0 | 0 | 0 | |___________________________________________________________|______ | | | | | | | | | | | | | | | |__ не использован: | | | доступный кластер | | | | | |_____ использовать нельзя | | | |______ не используется: не доступен | | |______ диск двусторонний с двойной плотностью Рис.3-8. Распределение памяти в FAT для типичного диска MS DOS FAT является высокоэффективной "бухгалтерской" системой, однако здесь могут возникнуть различные проблемы и необходимость компромисс- ных решений. Одна из проблем связана с наличием частично заполненного кластера в конце файла. При этом возникает проблема эффективности, связанная с использованием кластера большего размера, когда происходит выделение целого кластера, независимо от числа содержащихся в нем бай- тов. Например, десять 100-байтовых файлов на диске с кластерами разме- ром по 16 Кбайт, занимает 160 Кбайт дисковой памяти; те же файлы на диске с кластерами размером 1 Кбайт занимают только 10 Кбайт - разница составляет 150 Кбайт, что означает уменьшение объема памяти в 15 раз при использовании кластеров меньшего размера. С другой стороны, прог- рамма для 12-битовой FAT, показанная на рис.3-10, демонстрирует слож- ность (а следовательно, низкую скорость) перемещения в большом файле, имеющем длинный список ссылок между небольшими кластерами. Таким обра- зом, необходимо учитывать характер данных: приложения больших баз дан- ных работают эффективнее всего с кластерами большего размера; исполь- зуя кластеры меньшего размера, можно разместить на диске множество не- больших текстовых файлов разрабатывающий драйвер для дискового устрой- ства программист обычно устанавливает размер кластера). Вследствие отключения электроэнергии или беспорядочного выполне- ния программ возникают проблемы разрушения каталогов или таблиц разме- щения файлов, которые , не будучи исправлены, могут привести к более серьезным проблемам. Программа MS DOS CHKDSK может обнаруживать и фик- сировать некоторые дефекты. (см. КОМАНДЫ ПОЛЬЗОВАТЕЛЯ CHKDSK). Напри- мер, одной из типичных проблем является наличие списков "повисших" ссылок (dangling allocation lists), вызванное тем, что в каталоге от- сутствует указатель на начало списка. Подобная ситуация часто случа- ется, когда не был обновлен вход в каталог, так как не произошло зак- рытие файла перед выключением или перезагрузкой компьютера. Послед- ствия этого довольно безобидны: данные недоступны, однако это ограни- чение не влияет на другие операции по размещению файлов. Команда CHKDSK может решить эту проблему, создав новый вход каталога и связав его со списком. Другая трудность возникает, если размер файла во входе каталога не совпадает с его длиной, вычисляемой посредством просмотра списка ссылок в FAT. Это может повлечь за собой неверное выполнение программы и сообщения об ошибках MS DOS. Более сложная и реже возникающая проблема встречается, когда вход каталога задан правильно, однако список ссылок (весь или некоторая его часть) использован также другим входом каталога. Возникает тяжелая си- туация, так как запись или добавление в один файл изменяет содержимое другого. Эта ошибка обычно вызывает серьезное разрушение данных и/или каталога и приводит к краху системы. Подобная проблема встречается, когда список связей завершается свободным кластером вместо номера последнего кластера. Если свободный кластер распределен до исправления этой ошибки, ситуация в конце кон- цов превращается в описанный выше случай. Связанная с этим трудность возникает, когда встречается значение ссылки 1 или значение, превышаю- щее размер FAT. Помимо CHKDSK, для обслуживания FAT можно использовать множество коммерчески доступных сервисных программ. Например, программы реорга- низации диска (disk reorganizers) можно применять для изменения струк- туры FAT и упорядочения каталога так, чтобы все файлы на диске были размещены последовательно в области файлов данных и, разумеется, в FAT. 12-битовый FAT FFFH 007H 000H 003H _____ ____ ____ Резерв _____ | | _|_ | _|__ | ____|____ _|__ | __|_ | 00 |07| | |00| | | | | | | 00 | FF | 6F |____| F0 FF 0 F9 FF FF 03 40 |___| | | | |__| | | | | | | | | | | | | |______| |_____| |___| 004H 16-битовый FAT Резерв | 0003H ____________ _____ ____ ____ _____ ____ _____ _____ | | | | | | | | | | | | | | | | F8 FF FF FF 03 00 04 00 FF FF 06 00 07 00 FF FF 00 00 Вход FAT __________________________________________________ 12-битовый FAT |Резерв| 003H| 004H| FFFH| 006H| 007H| FFFH| 000H| 16-битовый FAT | |0003H|0004H|FFFFH|0006H|0007H|FFFFH|0000H| |______|_____|_____|_____|_____|_____|_____|_____| Вход каталога ____________ (указывает на |FILE1.TXT | 2 вход FAT) |___________| (указывает на ____________ 5 вход FAT) |FILE2.TXT | |___________| Область файлов данных Соответствующий вход FAT __________________________________ | FILE1.TXT | 2 |________________________________| | FILE1.TXT | 3 |________________________________| | FILE1.TXT | 4 |________________________________| | FILE2.TXT | 5 |________________________________| | FILE2.TXT | 6 |________________________________| | FILE2.TXT | 7 |________________________________| | не используется (доступен) | 8 |________________________________| Рис.3-9. Соответствие между FAT и областью файлов данных ;------ Получить номер следующей ссылки из 12-битовой FAT ;Параметры: ; ax = текущий номер слева ; ds:bx = адрес FAT (должна быть непрерывной) ; ; Возвращает: ; ax = номер следующей ссылки ; ; Использует ax, bx, cx next 12 proc near add bx,ax /ds:bx - частичный индекс shr ax,1 /ax = смещение /2 / сдвиг не нужен pushf / сохранить сдвиг add bx,ax /ds:bx - индекс номера следующей кластера mov ax,|bx| /ax = индекс номера следующего кластера popf / сдвиг не нужен jc shift / пропустить при использовании более 12 бит and ax,0fffh / менее 12 бит ret shift: mov cx,4 / cx = счетчик сдвигов shr ax,c1 /cx = ret next12 endp Рис.3-10. Ассемблерная программа для доступа к 12-битовой FAT 1.3.4. Корневой каталог Входы каталога, как в корневом, так и в подкаталогах, имеют длину 32 байта. Каждый вход включает имя файла и расширение, размер файла, начальный вход в FAT , время и дату создания или последней модификации файла и его атрибуты. Эта структура напоминает формат блоков управле- ния файлом (file control blocks - FCBs) для СР/М,используемый в файло- вой системе MS DOS, версии 1.х (см.ПРОГРАММИРОВАНИЕ В СРЕДЕ MS DOS: программирование для MS DOS; каталоги диска и метки тома). Соглашение о наименовании файлов в MS DOS происходит также из СР/М: восьмисимвольное имя файла и следующий за ним трехсимвольный тип файла, выравненные слева и при необходимости дополненные пробелами. В пределах ограничений символьного ряда имя и тип являются абсолютно произвольными. Время и дата задаются в формате, используемом другими функциями MS DOS и отражают время последней записи файла. На рис. 3-12 показан дамп сектора каталога объемом 512 байт, со- держащего 16 входов (каждый вход в этом примере занимает две строки). Байт со смещением ОАВН, содержащий значение 10Н обозначает, что вход начиная с адреса 0А0Н, относится к подкаталогу. Байт со смещением ___________________________________________________________________ ;------ Получить номер следующей ссылки из 16-битовой FAT ;Параметры: ; ax = текущий номер слева ; ds:bx = адрес FAT (должна быть непрерывной) ; ; Возвращает: ; ax = номер следующей ссылки ; ; Использует ax, bx, cx next 16 proc near add ax,ax /ax = смещение слева add bx,ax /ds:bx - индекс номера следующей ссылки mov ax,|bx| /ax = номер следующей ссылки ret next16 endp Рис.3-11. Ассемблерная программа для доступа к 16-битовой FAT 160Н, содержащий 0Е5Н, означает, что файл удален. Байт со смещением 8ВН и значением 08Н указывает, что вход каталога, начиная со смещения 80Н, является меткой тома. В конечном счете, байт со смещением 1Е0Н означает конец каталога, учитывая, что последующие входы каталога ни- когда не использовались и, следовательно, их поиск не требуется (вер- сии 2.0 и следующие). Показанный на рис.3-12 сектор на самом деле является примером сектора первого каталога в корневом каталоге загружаемого диска. Сле- дует отметить, что IO.SYS и MSDOS.SYS являются первыми двумя файлами в каталоге, а байт атрибута файла (смещение ОВН входа каталога), что оба файла имеют атрибуты скрытых (hidden) - бит 1 системных (бит 0 уста- навливается архивный бит (бит 5), указывающий на файлы для возможного копирования. Корневой каталог может иметь специальный тип входа, который назы- вается меткой тома, идентифицируется типом атрибута 08Н и используется для обозначения имени диска. Корневой каталог может содержать только одну метку тома. Корневой каталог может также включать входы, указыва- ющие на подкаталоги; такие входы идентифицируются типом атрибута 10Н и нулевым размером файла. Программы обработки подкаталогов должны осу- ществлять трассировку цепочек кластеров в FAT. Два других особых типа входов каталога встречаются только в под- каталогах. Эти входы содержат <имена_файлов>. и .., что означает соот- ветственно текущий каталог и родительский каталог для текущего. Эти специальные входы, называемые иногда альтернативными именами каталога (directory aliases), используются для быстрого перемещения в структуре каталога. Максимальная длина имени пути (pathname), допускаемая MS DOS, включающая имя файла и расширение (без спецификации дисковода), а также разделители имени подкаталога, составляет 64 символа. Размер са- 0 1 2 3 4 5 6 7 8 9 A B C D E F 0000 49 4F 20 20 20 20 20 20-53 59 53 27 00 00 00 00 10......SYS'..... 0010 00 00 00 00 00 00 59 53-89 0B 02 00 D1 12 00 00 ......YS....O.... 0020 4F 53 44 4F 53 20 20 20-53 59 53 27 00 00 00 00 MSDOS...SYS'.... 0030 00 00 00 00 00 00 41 49-52 0A 07 00 C9 43 00 00 ......AIR...IC.. 0040 41 4E 53 49 20 20 20 20-53 59 53 20 00 00 00 00 ANSI.....SYS.... 0050 00 00 00 00 00 00 41 49-52 0A 18 00 76 07 00 00 ......AIR...V... 0060 58 54 41 4C 4B 20 20 20-45 58 45 20 00 00 00 00 XTALK....EXE.... 0070 00 00 00 00 00 00 F7 7D-38 09 23 02 84 0B 01 00 ......W18....... 0080 4C 41 42 45 4C 20 20 20-20 20 20 08 00 00 00 00 LABEL........... 0090 00 00 00 00 00 00 8C 20-2A 09 00 00 00 00 00 00 .........*.D..R. 00A0 4C 4F 54 55 53 20 20 20-20 20 20 10 00 00 00 00 LOTUS........... 00B0 00 00 00 00 00 00 E0 OA-E1 C6 A6 01 00 00 00 00 ......'.a.&.a... 00C0 4C 54 53 4C 4F 41 44 20-43 4F 4D 20 00 00 00 00 LTSLOAD.COM..... 00D0 00 00 00 00 00 00 E0 0A-E1 06 A7 01 A0 27 00 00 ......'.a....... 00E0 4D 43 49 2D 53 46 20 20-58 54 4B 20 00 00 00 00 MCI-SE...XTK.... 00F0 00 00 00 00 00 00 46 19-32 0D B1 01 79 04 00 00 .......F.2.1.y.. 0100 58 54 41 4C 4B 20 20 20-48 4C 50 20 00 00 00 00 XTALK...HLP..... 0110 00 00 00 00 00 00 C5 6D-73 07 A3 02 AF 88 00 00 ......Ems.#..... 0120 54 58 20 20 20 20 20 20-43 4F 4D 20 00 00 00 00 TX COM.... 0130 00 00 00 00 00 00 05 61-65 0C 39 01 E8 20 00 00 ................. 0140 43 4F 4D 4D 41 4E 44 20-43 4F 4D 20 00 00 00 00 COMMAND COM ..... 0150 00 00 00 00 00 00 41 49-52 0A 27 00 55 3F 00 00 ......AIR.'.UP... 0160 E5 32 33 20 20 20 20 20-45 58 45 20 00 00 00 00 e23 EXE..... 0170 00 00 00 00 00 00 9C B2-85 0B 42 01 80 5F 01 00 ........2..B..... 0180 47 44 20 20 20 20 20 20-44 52 56 20 00 00 00 00 GD.......DRV..... 0190 00 00 00 00 00 00 E0 0A-E1 06 9A 01 5B 08 00 00 .......'a...'.... 01A0 4B 42 20 20 20 20 20 20-44 52 56 20 00 00 00 00 KB.......DRV..... 01B0 00 00 00 00 00 00 E0 0A-E1 06 9D 01 60 01 00 00 .......'a...'.... 01C0 50 52 20 20 20 20 20 20-44 52 56 20 00 00 00 00 PR.......DRV..... 01D0 00 00 00 00 00 00 E0 0A-E1 06 9E 01 49 01 00 00 .......'a..'..... 01E0 00 F6 F6 F6 F6 F6 F6 F6-F6 F6 F6 F6 F6 F6 F6 F6 ................. 01F0 F6 F6 F6 F6 F6 F6 F6 F6-F6 F6 F6 F6 F6 F6 F6 F6 ................. Рис.3-12. Шестнадцатеричный дамп сектора каталога объемом 512 байт мой структуры каталога ограничен только числом входов корневого ката- лога и имеющимся объемом дисковой памяти. 1.3.5. Область файла Область файла содержит подкаталоги, данных файла и нераспределен- ные кластеры. Область разделяется на кластеры фиксированного размера и использование каждого кластера регламентируется соответствующим входом FAT. 2. Другие запоминающие устройства MS DOS Как было упомянуто выше, MS DOS поддерживает и другие типы запо- минающих устройств, такие, как магнитоленточные устройства и ПЗУ на компактных дисках (CD ROM disks). Магнитоленточные устройства чаще всего применяются для архивирования данных и последовательной обра- ботки транзакций, таким образом, этот тип устройства здесь не рассмат- ривается. ПЗУ на компактных дисках представляют собой компактные лазерные диски, хранящие огромное количество информации - одна сторона компак- тного диска может содержать 500 Мбайт данных. Однако в современной технологии обработки компактных дисков имеются некоторые недостатки. Например, запись данных на эти диски невозможна - информация записыва- ется на компактный диск на заводе-изготовителе и доступна только для чтения. Кроме того, время доступа для компактного диска значительно больше, чем для большинства систем, использующих магнитные диски. Но, несмотря на эти ограничения, способность поддерживать большие объемы информации делает компактные диски хорошим средством хранения больших объемов статической информации. Уильям Вонг